Phenquestions
Ponieważ nawet jeśli trzymasz się wydań długoterminowego wsparcia (LTS), dystrybucje Linuksa są często bardziej narażone na ryzyko niż komputery z systemem Windows, które nagle i spektakularnie wypadną z biznesu.
Dlaczego w tak wielu przypadkach tak jest??
- Kompatybilność sprzętowa, w tym dla podstawowych komponentów, takich jak procesory graficzne, pozostaje znaczącym wyzwaniem, ponieważ wielu dostawców nadal nie obsługuje dystrybucji Linuksa, pozostawiając społeczności tworzenie obejścia;
- Model finansowy open source nie zachęca, a tym bardziej nie wymaga, dokładnych procesów kontroli jakości;
- A dla tych, którzy nadążają za najnowszymi wydaniami, fundamentalne zmiany w narzędziach do zarządzania pakietami mają nieprzyjemny zwyczaj czasami blokowania systemu przez otwieranie nieodwracalnych błędów zależności w Puszce Pandory. Naprawienie ich, nawet jeśli to możliwe, może wymagać wykopania kilkudniowych króliczych nor. To, co może wydawać się dobrą nauką dla początkującego użytkownika, może stać się przełomową frustracją dla weterana, który ma zamiar przejść do systemu Windows.
A problem ze stabilnością Linuksa rozwścieczył wielu użytkowników. Przeglądaj wiele wątków użytkowników w niebezpieczeństwie na AskUbuntu.com, a natkniesz się na mnóstwo sfrustrowanych plakatów, którzy wypróbowali wszystko i ostatecznie zdecydowali, że jedynym sposobem na postęp jest instalacja od zera.
Chociaż początkowo może to być swego rodzaju procesem uczenia się, zachęcającym użytkowników do okresowego ponownego przemyślenia, w jaki sposób mogą uczynić swój system szczuplejszym i usprawnić proces odzyskiwania, po pewnym czasie staje się to nic lepszego niż duża, pochłaniająca czas uciążliwość. Prędzej czy później nawet najbardziej zaawansowani użytkownicy energii zaczną pragnąć stabilności.
Używam Linuksa jako mojego codziennego systemu operacyjnego od ponad 10 lat i przeszedłem przez mój sprawiedliwy udział w niechcianych czystych instalacjach. Tak wielu, że obiecałem, że moja ostatnia ponowna instalacja będzie moją ostatnią. Od tego czasu opracowałem następującą metodologię. I działało, aby mój system Lubuntu działał tak dobrze, jak w dniu, w którym go zainstalowałem bez ponownej instalacji. Oto co robię.
Rozważania: co musisz zrobić, aby wykonać kopię zapasową?
Zanim zdecydujesz się na strategię tworzenia kopii zapasowych, musisz poznać kilka podstaw:
- Czego potrzebujesz do tworzenia kopii zapasowych? Czy musisz wykonać kopię zapasową pełnej partycji/woluminu, czy tylko katalogu domowego użytkownika??
- Czy strategia tworzenia przyrostowych kopii zapasowych wystarczy w Twoim przypadku?? A może musisz wykonać pełne kopie zapasowe??
- Czy kopia zapasowa musi być zaszyfrowana??
- Jak łatwy jest proces przywracania??
Mój system tworzenia kopii zapasowych opiera się na mieszance metodologii.
Używam Timeshift jako podstawowego systemu tworzenia kopii zapasowych, który wykonuje przyrostowe migawki. I trzymam na miejscu pełną kopię zapasową dysku, która wyklucza katalogi, które nie zawierają danych użytkownika. W stosunku do systemu root są to:
- /dev
- /proc
- /sys
- /tmp
- /biegać
- /mnt
- /głoska bezdźwięczna
- /zgubione+znalezione
Wreszcie mam jeszcze dwie kopie zapasowe. Jednym z nich jest (rzeczywista) pełna partycja systemowa do tworzenia kopii zapasowej obrazu przy użyciu Clonezilla USB na żywo. Clonezilla pakuje serię niskopoziomowych narzędzi do replikacji instalacji. Druga to pełna kopia zapasowa systemu poza siedzibą firmy, którą przesyłam do AWS S3 mniej więcej raz w roku, gdy mam do dyspozycji świetne łącze danych.
Opcje narzędzi do tworzenia kopii zapasowych
W dzisiejszych czasach wybór narzędzi, z których możesz korzystać, jest duży.
Obejmuje:
- Dobrze znane CLI, takie jak rsync, które mogą być skryptowane i wywoływane ręcznie jako zadanie cron
- Programy takie jak Déjà Dup, Duplicity, Bacula, które zapewniają GUI do tworzenia i automatyzacji planów tworzenia kopii zapasowych na lokalnych lub zewnętrznych serwerach docelowych, w tym obsługiwanych przez zwykłych dostawców chmury
- Oraz narzędzia współpracujące z płatnymi usługami w chmurze, takimi jak CrashPlan, SpiderOak One i CloudBerry. Ta ostatnia kategoria obejmuje usługi, które same zapewniają tanią przestrzeń do przechowywania w chmurze, więc oferta jest kompletnie niekończąca się.
Zasada 3-2-1
Przedstawię krótki przegląd narzędzi, których obecnie używam na mojej głównej maszynie.
Chociaż napisałem kilka skryptów Bash, aby pobrać niezbędne pliki konfiguracyjne do mojej głównej pamięci masowej w chmurze, której używam do codziennych plików, ten (niezbędny) składnik mojego planu tworzenia kopii zapasowych po prostu tworzy kopię zapasową całej maszyny, w tym maszyn wirtualnych i systemu pliki, które należy pominąć lub utworzyć kopię zapasową osobno w bardziej zniuansowanych podejściach.
Jego głównym założeniem jest przestrzeganie zasady tworzenia kopii zapasowych 3-2-1. Takie podejście powinno zapewnić bezpieczeństwo danych — w tym głównego systemu operacyjnego — w niemal każdym scenariuszu awarii.
Reguła mówi, że powinieneś zachować:
- 3 kopie Twoich danych. Zawsze mówię, że jest to trochę mylące, ponieważ tak naprawdę oznacza to, że powinieneś zachować swoje podstawowe źródło danych i dwie kopie zapasowe. Po prostu określiłbym to jako „dwie kopie zapasowe”
- Te dwie kopie zapasowe powinny być przechowywane na różnych nośnikach pamięci. Wróćmy do prostych terminów związanych z komputerami domowymi. Możesz napisać prosty skrypt rsync, który (przyrostowo) kopiuje główny dysk SSD do innego podłączonego nośnika pamięci — powiedzmy, że dysk twardy podłączony do następnego portu SATA na płycie głównej. Ale co się stanie, jeśli Twój komputer się zapali lub Twój dom zostanie okradziony?? Zostałbyś bez podstawowego źródła danych i nie miałbyś kopii zapasowej. Zamiast tego możesz wykonać kopię zapasową dysku podstawowego na Network Attached Storage (NAS) lub po prostu użyć Clonezilli, aby zapisać go na zewnętrznym dysku twardym.
- Jedna z dwóch kopii zapasowych powinna być przechowywana poza siedzibą. Kopie zapasowe poza siedzibą firmy są niezbędne, ponieważ w przypadku katastrofalnego zdarzenia naturalnego, takiego jak na przykład powódź, cały dom może zostać zniszczony. Mniej dramatycznie, duże przepięcie mogłoby usmażyć całą podłączoną elektronikę w domu lub wszystkie podłączone do określonego obwodu (dlatego ma sens utrzymywanie jednej z kopii zapasowych na miejscu bez podłączenia do źródła zasilania – przykładem może być prosty zewnętrzny dysk twardy/SDD ).Technicznie rzecz biorąc, „poza siedzibą” jest wszędzie, gdzie jest odległa lokalizacja. Możesz więc użyć Clonezilli do zdalnego zapisania obrazu systemu operacyjnego na komputerze służbowym lub podłączonym do niego dysku przez Internet. Obecnie przechowywanie w chmurze jest wystarczająco tanie, aby niedrogo zainstalować nawet pełne obrazy dysków. Z tego powodu raz w roku wykonuję pełną kopię zapasową systemu w wiadrze Amazon S3. Korzystanie z AWS zapewnia również ogromną dodatkową nadmiarowość.
Moja implementacja kopii zapasowej
Moje podejście do kopii zapasowych opiera się na kilku prostych zasadach:
- Chcę, aby wszystko było tak proste, jak to możliwe;
- Chcę zapewnić sobie jak największą redundancję, jaką mogę osiągnąć;
- Chcę przynajmniej przestrzegać zasady 3-2-1
Więc robię co następuje.
- Na moim komputerze trzymam dodatkowy dysk, który służy wyłącznie do przechowywania Przesunięcie czasu punkty przywracania. Ponieważ poświęcam na to cały dysk, mam dość dużo miejsca na zabawę. Prowadzę codzienną, miesięczną i tygodniową kopię zapasową. Jak dotąd Timeshift to wszystko, czego potrzebowałem, aby cofnąć system o kilka dni, zanim coś, na przykład nowy pakiet, będzie miało negatywny wpływ na inne części systemu. Nawet jeśli nie możesz przejść przez GRUB, Timeshift może być używany jako CLI z uprawnieniami roota do naprawy systemu. To niezwykle wszechstronne i przydatne narzędzie. To pierwsza kopia na miejscu.
- Trzymam dodatkowy dysk na moim komputerze, który jest używany wyłącznie do przechowywania obrazów Clonezilla mojego głównego dysku. Ponieważ te obrazy byłyby dla mnie przydatne tylko w przypadku niepowodzenia Timeshift, biorę je tylko raz na trzy do sześciu miesięcy. To jest druga kopia na miejscu.
- Używając Clonezilli, tworzę dodatkowy dysk twardy, który trzymam w domu poza komputerem. Z wyjątkiem tego, że dla tego dysku twardego używam kopii zapasowej urządzenia zamiast kopii zapasowej obrazu urządzenia, jak na poprzednim obrazie - więc byłoby dobrze, gdyby mój główny dysk był zamurowany. Gdybym miał odzyskać na przykład z wewnętrznego dysku kopii zapasowej Clonezilla, musiałbym najpierw wykonać proces przywracania. Zakładając, że pozostałe elementy systemu są w dobrym stanie po awarii dysku twardego, teoretycznie wystarczy podłączyć ten dysk do płyty głównej, aby zacząć z niego korzystać. To jest trzecia kopia na miejscu.
- Wreszcie, mniej więcej raz na sześć miesięcy, przesyłam obraz mojego systemu wygenerowany przez Clonezillę do AWS S3. Nie trzeba dodawać, że jest to długie przesyłanie wieloczęściowe i należy je wykonać z połączenia internetowego z dobrym łączem przesyłania.
W sumie mój system obejmuje trzy kopie na miejscu i jedną kopię poza siedzibą mojego głównego pulpitusite.
Główne dania na wynos
- Wszyscy użytkownicy Linuksa powinni mieć solidne strategie tworzenia kopii zapasowych
- Reguła tworzenia kopii zapasowych 3-2-1 jest dobrym miernikiem zapewnienia bezpieczeństwa danych w praktycznie każdych okolicznościach.
- Do tworzenia kopii zapasowych używam kombinacji Timeshift i Cloudzilla, chociaż na rynku jest wiele innych opcji, w tym płatnych. Do przechowywania w chmurze używam prostego wiadra AWS S3, chociaż znowu istnieją zintegrowane usługi, które obejmują zarówno oprogramowanie, jak i narzędzia do przechowywania.
