För även om du håller dig till Long Term Support (LTS) -utgåvor är Linux-distributioner ofta i grund och botten mer utsatta än Windows-maskiner för att - plötsligt och spektakulärt - gå ur drift.
Varför i så många fall är det så??
- Hårdvarukompatibilitet, inklusive för väsentliga komponenter som GPU: er, är fortfarande en betydande utmaning med många leverantörer som fortfarande inte stöder Linux-distributioner, vilket överlåter till samhället att skapa lösningar;
- Öppen källkods ekonomiska modell uppmuntrar inte, mycket mindre kräver grundliga QA-processer;
- Och för dem som håller jämna steg med släppande kanter, grundläggande förändringar av pakethanteringsverktygen har en otrevlig vana att ibland sätta in systemet genom att öppna en irreparabel Pandoras låda med beroendefel. Att reparera dessa, även när det är möjligt, kan innebära att man gör ner långa kaninhål. Vad som kan verka som en bra inlärningsupplevelse för en förstagångsanvändare kan bli en frustrerande frustration för en veterananvändare på väg att hoppa skepp till Windows.
Och Linuxs stabilitetsfråga har rasat många användare. Bläddra bland många användartrådar på AskUbuntu.com och du kommer att stöta på massor av frustrerade affischer som har provat allt och i slutändan beslutat att den enda vägen framåt är att installera från grunden.
Medan detta görs kan det inledningsvis vara en slags inlärningsprocess, vilket uppmuntrar användarna att regelbundet ompröva hur de kan göra sitt system smalare och effektivisera återhämtningsprocessen, efter ett tag blir det inget bättre än en stor, tidskrävande olägenhet. Förr eller senare kommer även de mest avancerade kraftanvändarna att kräva stabilitet.
Jag har använt Linux som mitt dagliga operativsystem i mer än 10 år och har gått igenom min rättvisa andel av oönskade rena installationer. Så många faktiskt att jag lovade att min senaste ominstallation skulle vara min sista. Sedan dess har jag utvecklat följande metod. Och det har fungerat för att hålla mitt Lubuntu-system lika bra som den dag jag installerade det utan en ominstallation sedan dess. Här är vad jag gör.
Överväganden: Vad behöver du för att säkerhetskopiera?
Innan du bestämmer dig för en reservstrategi måste du ta reda på några grundläggande:
- Vad behöver du för att säkerhetskopiera? Behöver du säkerhetskopiera hela partitionen / volymen eller bara hemanvändarkatalogen?
- Räcker en inkrementell reservstrategi för ditt användningsfall? Eller behöver du ta fullständiga säkerhetskopior?
- Behöver säkerhetskopian krypteras?
- Hur lätt behöver du att återställningsprocessen ska vara?
Mitt backup-system är baserat på en blandning av metoder.
Jag använder Timeshift som mitt primära säkerhetskopieringssystem, vilket tar stegvisa ögonblicksbilder. Och jag håller en fullständig säkerhetskopia på webbplatsen som utesluter kataloger som inte innehåller användardata. I förhållande till systemets rot är dessa:
- / dev
- / proc
- / sys
- / tmp
- /springa
- / mnt
- /media
- / förlorat + hittat
Slutligen behåller jag ytterligare två säkerhetskopior. En av dessa är en (riktig) fullständig systempartition till säkerhetskopiering av bilder med hjälp av en Clonezilla live USB. Clonezilla paketerar en serie verktyg på låg nivå för replikering av installationer. Och den andra är en fullständig säkerhetskopia utanför webbplatsen som jag laddar upp till AWS S3 ungefär en gång om året när jag har en stor dataöverföring till mitt förfogande.
Alternativ för säkerhetskopieringsverktyg
Dessa dagar är urvalet av verktyg du kan använda stort.
Det inkluderar:
- Välkända CLI: er som rsync som kan skripts och kallas som cron-jobb manuellt
- Program som Déjà Dup, Duplicity, Bacula som tillhandahåller GUI för att skapa och automatisera reservplaner till lokala eller externa destinationsservrar, inklusive de som drivs av vanliga molnleverantörer
- Och verktyg som gränssnitt med betalda molntjänster som CrashPlan, SpiderOak One och CloudBerry. Den sista kategorin inkluderar tjänster som själva erbjuder billigt molnlagringsutrymme så att erbjudandet är helt slut.
3-2-1-regeln
Jag kommer att ge en snabb översikt över de verktyg jag för närvarande använder på min huvudmaskin.
Även om jag har skrivit några Bash-skript för att få viktiga konfigurationsfiler till mitt huvudsakliga molnlagring, som jag använder för dagliga filer, säkerhetskopierar denna (den väsentliga) komponenten i min reservplan helt enkelt hela maskinen, inklusive virtuella maskiner och system filer som bör utelämnas eller säkerhetskopieras separat i mer nyanserade metoder.
Dess centrala förutsättning är att följa 3-2-1-reservregeln. Detta tillvägagångssätt ska hålla dina data - inklusive ditt huvud-operativsystem - säkra i nästan alla felscenarier.
Regeln säger att du ska behålla:
- 3 kopior av dina data. Jag säger alltid att detta är lite felaktigt eftersom det faktiskt betyder att du ska behålla din primära datakälla och två säkerhetskopior. Jag skulle helt enkelt hänvisa till detta som "två säkerhetskopior"
- Dessa två säkerhetskopior ska förvaras på olika lagringsmedier. Låt oss återföra detta till enkla termer för hemdator. Du kan skriva ett enkelt rsync-skript som (stegvis) kopierar din huvudsakliga SSD till ett annat anslutet lagringsmedium - låt oss säga en hårddisk ansluten till nästa SATA-port på moderkortet. Men vad händer om din dator tar eld eller ditt hus är rånat? Du skulle vara kvar utan din primära datakälla och har ingen säkerhetskopia. Istället kan du säkerhetskopiera din primära disk till en Network Attached Storage (NAS) eller helt enkelt använda Clonezilla för att skriva den till en extern hårddisk.
- En av de två säkerhetskopiorna ska lagras utanför webbplatsen. Säkerhetskopiering utanför webbplatsen är viktig eftersom i händelse av en katastrofal naturlig händelse som översvämning till exempel kan hela ditt hus förstöras. Mindre dramatiskt kan en större överspänningshändelse steka all ansluten elektronik i ett hus eller alla som är på en viss krets (det är därför det är vettigt att hålla en av säkerhetskopiorna på plats oanslutna till en strömförsörjning - ett exempel skulle vara en enkel extern hårddisk / SDD ).Tekniskt sett är "offsite" var som helst som är en avlägsen plats. Så du kan använda Clonezilla för att fjärrskriva en bild av ditt operativsystem till din arbetsdator eller en enhet ansluten till den via internet. Dessa dagar är molnlagring tillräckligt billigt för att på ett överkomligt sätt installera bilder med hela enheter. Av den anledningen säkerhetskopierar jag mitt system helt, en gång per år, till en Amazon S3-hink. Att använda AWS ger dig också massiv extra redundans.
Min backupimplementering
Min inställning till säkerhetskopior baseras på några enkla policyer:
- Jag vill hålla saker så enkla som möjligt;
- Jag vill ge mig själv den mest redundans som jag rimligen kan uppnå;
- Jag vill åtminstone följa 3-2-1-regeln
Så jag gör enligt följande.
- Jag har en extra enhet på skrivbordet som enbart används för att hysa Timehift återställningspunkter. Eftersom jag ägnar en hel skiva åt den har jag ganska mycket utrymme att leka med. Jag håller en backup varje dag, en månad och en vecka. Hittills är Timeshift allt jag behöver för att rulla systemet tillbaka några dagar till en punkt innan något, som ett nytt paket, hade en negativ inverkan på andra delar av systemet. Även om du inte kan komma förbi GRUB kan Timeshift användas som en CLI med rootbehörighet för att reparera systemet. Det är ett otroligt mångsidigt och användbart verktyg. Detta är en första kopia på plats.
- Jag har en extra enhet på skrivbordet som enbart används för att hysa Clonezilla-bilder av min huvudenhet. Eftersom dessa bilder bara skulle vara användbara för mig i händelse av att Timeshift misslyckades tar jag bara dessa en gång var tredje till sex månader. Detta är en andra kopia på plats.
- Med hjälp av Clonezilla skapar jag en extra hårddisk som jag håller hemma utanför datorn. Förutom att jag, för den här hårddisken, använder en enhetsenhetskopiering snarare än en enhetsbildsäkerhetskopia som i föregående bild - så att det skulle vara bra att gå omedelbart om min primära enhet var murad. Om jag till exempel skulle återhämta mig från den interna Clonezilla backup-enheten skulle jag behöva följa en återställningsprocess. Förutsatt att de andra systemkomponenterna är i gott skick efter ett hårddiskfel, skulle jag teoretiskt bara behöva ansluta den här enheten till moderkortet för att börja använda den. Detta är en tredje kopia på plats.
- Slutligen laddar jag upp en Clonezilla-genererad bild av mitt system en gång var sjätte månad till AWS S3. Naturligtvis är detta en lång uppladdning i flera delar och måste göras från en internetanslutning med en bra uppladdningslänk.
Sammantaget involverar mitt system tre kopior på plats och en kopia på plats av mitt huvudskrivbord.
Huvudavhämtningar
- Alla Linux-användare bör ha robusta reservstrategier på plats
- Säkerhetskopieringsregeln 3-2-1 är en bra måttstock för att säkerställa att dina data är säkra under praktiskt taget alla omständigheter.
- Jag använder en kombination av Timeshift och Cloudzilla för att skapa mina säkerhetskopior även om det finns många andra alternativ, inklusive betalda, på marknaden. För molnlagring använder jag en enkel AWS S3-hink, även om det åter finns integrerade tjänster som inkluderar både programvara och lagringsverktyg.