Phenquestions
Deoarece, chiar dacă vă mențineți la versiunile de asistență pe termen lung (LTS), distribuțiile Linux sunt deseori în mod fundamental mai expuse riscului ca mașinile Windows să renunțe - brusc și spectaculos - la afaceri.
De ce, în atât de multe cazuri, este așa?
- Compatibilitatea hardware, inclusiv pentru componentele esențiale, cum ar fi GPU-urile, rămâne o provocare semnificativă, mulți furnizori încă nu acceptă distribuțiile Linux, lăsând în sarcina comunității să creeze soluții alternative;
- Modelul financiar open source nu stimulează, cu atât mai puțin necesită, procese aprofundate de QA;
- Iar pentru cei care țin pasul cu versiunile de sângerare, modificările fundamentale ale instrumentelor de gestionare a pachetelor au un obicei urât de a împiedica uneori sistemul prin deschiderea unei cutii ireparabile a Pandorei de erori de dependență. Repararea acestora, chiar și atunci când este posibil, poate presupune realizarea unor găuri de iepure de câteva zile. Ceea ce ar putea părea o experiență bună de învățare pentru un utilizator pentru prima dată poate deveni o frustrare de rupere a afacerii pentru un utilizator veteran aflat în pragul saltului navei către Windows.
Și problema stabilității Linux a înfuriat mulți utilizatori. Răsfoiți multe subiecte de utilizator în dificultate pe AskUbuntu.com și veți întâlni o mulțime de postere frustrate care au încercat totul și au decis în cele din urmă că singura cale de urmat este instalarea de la zero.
În timp ce face acest lucru poate fi inițial un fel de proces de învățare, încurajând utilizatorii să regândească periodic modul în care își pot simplifica sistemul și eficientiza procesul de recuperare, după un timp nu devine nimic mai bun decât o mare neplăcere care pierde timpul. Mai devreme sau mai târziu, chiar și cei mai avansați utilizatori de energie vor începe să dorească stabilitate.
Folosesc Linux ca sistem de operare de zi cu zi de mai bine de 10 ani și am trecut prin partea mea echitabilă de instalații curate nedorite. Atât de multe, de fapt, că am promis că ultima mea reinstalare va fi ultima mea. De atunci, am dezvoltat următoarea metodologie. Și a funcționat pentru ca sistemul meu Lubuntu să funcționeze la fel de bine ca în ziua în care l-am instalat fără o reinstalare de atunci. Iată ce fac.
Considerații: Ce trebuie să faceți backup?
Înainte de a decide asupra unei strategii de rezervă, trebuie să vă dați seama de câteva elemente fundamentale:
- De ce aveți nevoie pentru a face backup? Trebuie să faceți copie de rezervă a partiției / volumului complet sau doar a directorului utilizatorului de acasă?
- O strategie de rezervă incrementală va fi suficientă pentru cazul dvs. de utilizare? Sau trebuie să faceți copii de rezervă complete?
- Copia de rezervă trebuie criptată?
- Cât de ușor aveți nevoie pentru a fi procesul de restaurare?
Sistemul meu de rezervă se bazează pe un amestec de metodologii.
Folosesc Timeshift ca sistem principal de rezervă, care realizează instantanee incrementale. Și păstrez o copie de rezervă completă a discului pe site, care exclude directoare care nu conțin date de utilizator. Relativ la rădăcina sistemului acestea sunt:
- / dev
- / proc
- / sys
- / tmp
- /alerga
- / mnt
- /mass-media
- / pierdut + găsit
În cele din urmă, păstrez încă două copii de rezervă. Una dintre acestea este o partiție de sistem completă (reală) pentru salvarea imaginii folosind un Clonezilla USB live. Clonezilla împachetează o serie de instrumente de nivel scăzut pentru replicarea instalațiilor. Și al doilea este o copie de rezervă completă a sistemului în afara site-ului, pe care o încarc pe AWS S3 aproximativ o dată pe an, ori de câte ori am o legătură ascendentă excelentă la dispoziția mea.
Opțiuni Instrumente de rezervă
În aceste zile, selecția de instrumente pe care le puteți utiliza este mare.
Include:
- CLI-uri bine cunoscute, cum ar fi rsync, care pot fi scriptate și apelate manual ca cron job
- Programe precum Déjà Dup, Duplicity, Bacula care oferă GUI-uri pentru a crea și automatiza planuri de backup pe servere de destinație locale sau în afara site-ului, inclusiv cele operate de furnizori de cloud obișnuiți
- Și instrumente care interacționează cu servicii cloud plătite precum CrashPlan, SpiderOak One și CloudBerry. Ultima categorie include servicii care oferă spațiul de stocare în cloud ieftin, astfel încât oferta este complet cap la cap.
Regula 3-2-1
Voi oferi o prezentare rapidă a instrumentelor pe care le folosesc în prezent pe mașina mea principală.
Deși am scris câteva scripturi Bash pentru a obține fișiere de configurare esențiale în spațiul meu principal de stocare în cloud, pe care le folosesc pentru fișierele de zi cu zi, această componentă (esențială) a planului meu de backup face pur și simplu backup pentru întreaga mașină, inclusiv mașini și sisteme virtuale fișiere care ar trebui lăsate în afara sau copiate separat în abordări mai nuanțate.
Premisa sa centrală este respectarea regulii de rezervă 3-2-1. Această abordare ar trebui să vă păstreze datele - inclusiv sistemul de operare principal - în siguranță în aproape orice scenariu de eșec.
Regula prevede că ar trebui să păstrați:
- 3 copii ale datelor dvs. Întotdeauna spun că acesta este un pic greșit, deoarece înseamnă de fapt că ar trebui să păstrați sursa de date primară și două copii de rezervă. M-aș referi pur și simplu la „două copii de rezervă”
- Aceste două copii de rezervă ar trebui păstrate pe suporturi de stocare diferite. Să readucem acest lucru la termeni simpli de calcul acasă. Puteți scrie un script rsync simplu care (în mod incremental) copiază SSD-ul principal într-un alt suport de stocare atașat - să presupunem un HDD atașat la următorul port SATA de pe placa de bază. Dar ce se întâmplă dacă computerul tău ia foc sau casa îți este jefuită? Ați rămâne fără sursa dvs. primară de date și nu aveți nicio copie de rezervă. În schimb, ați putea face o copie de rezervă a discului dvs. primar într-un Network Attached Storage (NAS) sau pur și simplu utilizați Clonezilla pentru a-l scrie pe un hard disk extern.
- Una dintre cele două copii de rezervă ar trebui să fie stocată în afara locației. Copiile de rezervă în afara locației sunt vitale, deoarece, în cazul unui eveniment natural catastrofal, cum ar fi inundațiile, de exemplu, întreaga casă ar putea fi distrusă. Mai puțin dramatic, un eveniment major de suprasolicitare ar putea prăji toate componentele electronice conectate dintr-o casă sau pe toate cele dintr-un anumit circuit (de aceea este logic să păstrăm una dintre copiile de rezervă la fața locului neconectate la o sursă de alimentare - un exemplu ar fi un simplu HDD / SDD extern ).Din punct de vedere tehnic, „offsite” este oriunde, care este o locație la distanță. Deci, ați putea folosi Clonezilla pentru a scrie de la distanță o imagine a sistemului dvs. de operare pe computerul de lucru sau o unitate atașată acestuia, prin internet. În zilele noastre, stocarea în cloud este suficient de ieftină pentru a instala la un preț accesibil chiar și imagini pe unitatea completă. Din acest motiv, îmi fac o copie completă a sistemului, o dată pe an, într-o găleată Amazon S3. Utilizarea AWS vă oferă, de asemenea, o redundanță suplimentară masivă.
Implementarea mea de rezervă
Abordarea mea asupra copiilor de rezervă se bazează pe câteva politici simple:
- Vreau să păstrez lucrurile cât mai simple;
- Vreau să-mi ofer cea mai mare redundanță pe care o pot realiza în mod rezonabil;
- Vreau, cel puțin, să urmez regula 3-2-1
Deci procedez după cum urmează.
- Păstrez o unitate suplimentară pe desktop, care este utilizată exclusiv pentru găzduire Timehsift restabiliți punctele. Deoarece îi dedic un întreg disc, am destul spațiu cu care să mă joc. Păstrez o copie de rezervă zilnică, lunară și săptămânală. Până acum, Timeshift este tot ce mi-a trebuit pentru a reveni la sistem cu câteva zile până la un punct înainte ca ceva, cum ar fi un pachet nou, să aibă un impact negativ asupra altor părți ale sistemului. Chiar dacă nu puteți trece de GRUB, Timeshift poate fi folosit ca CLI cu privilegii de root pentru a repara sistemul. Este un instrument uimitor de versatil și util. Aceasta este o primă copie la fața locului.
- Păstrez o unitate suplimentară pe desktop, care este utilizată exclusiv pentru adăpostirea imaginilor Clonezilla ale unității mele principale. Deoarece aceste imagini mi-ar fi cu adevărat utile doar în cazul în care Timeshift eșua, le iau doar o dată la trei până la șase luni. Aceasta este a doua copie la fața locului.
- Folosind Clonezilla, creez un hard disk suplimentar pe care îl păstrez acasă extern PC-ului. Cu excepția faptului că, pentru acest hard disk, folosesc mai degrabă o copie de rezervă dispozitiv-dispozitiv decât o copie de siguranță a imaginii dispozitivului ca în imaginea anterioară - astfel încât ar fi bine să merg instantaneu dacă unitatea mea principală ar fi blocată. Dacă ar fi să mă recuperez de pe unitatea internă de rezervă Clonezilla, de exemplu, ar trebui să urmez mai întâi un proces de restaurare. Presupunând că celelalte componente ale sistemului sunt în stare bună de funcționare în urma unei defecțiuni a hard disk-ului, teoretic ar fi nevoie doar să conectez această unitate la placa de bază pentru a începe să o folosesc. Aceasta este a treia copie la fața locului.
- În cele din urmă, o dată la șase luni, cam așa, încarc o imagine generată de Clonezilla a sistemului meu pe AWS S3. Inutil să spun că aceasta este o încărcare multipartă lungă și trebuie efectuată dintr-o conexiune la internet cu un link bun de încărcare.
În total, sistemul meu implică trei copii la fața locului și o copie la fața locului a desktopului meu principal.
Principalele Takeaways
- Toți utilizatorii de Linux ar trebui să aibă la dispoziție strategii de backup solide
- Regula de rezervă 3-2-1 este un bun criteriu pentru a vă asigura că datele dvs. sunt sigure în aproape toate circumstanțele.
- Folosesc o combinație de Timeshift și Cloudzilla pentru a-mi crea copiile de rezervă, deși există o mulțime de alte opțiuni, inclusiv cu plată, pe piață. Pentru stocarea în cloud, folosesc o bucket AWS S3 simplă, deși, din nou, există servicii integrate care includ atât software cât și instrumente de stocare.
