Najlepsze praktyki sprawdzania kopii zapasowych?

Często zdarza się, że administrator tworzy system automatycznego tworzenia kopii zapasowych i zapomina o nim. Dopiero gdy system zawiedzie, powiadomienia administratora, że ​​system tworzenia kopii zapasowych zepsuł się wcześniej lub kopie zapasowe są nie do odzyskania z powodu jakiejś usterki i nie ma on bieżącej kopii zapasowej do przywrócenia ... Więc jakie są najlepsze praktyki, aby uniknąć takich sytuacji?

Przeprowadzaj ćwiczenia przeciwpożarowe ... co kilka miesięcy dobrze jest powiedzieć, że system XYZ jest wyłączony ... a następnie przejść przez proces przywracania go do nowej maszyny wirtualnej itp. Utrzymuje to uczciwość i pomaga złapać błędy

tryb mydła: WŁĄCZONY

Powiedziałbym, że tak proste, że kopie zapasowe, które nie są regularnie testowane, są bezwartościowe.

W mojej poprzedniej pracy mieliśmy politykę, że każdy system (produkcja, testy, monitorowanie rozwoju itp.) Powinien być przywracany co 6 miesięcy.

Było to również zadanie najbardziej młodszego administratora, więc dokumentacja była aktualna. Junior jest definiowany przez to, ile pracy włożył w konkretny system, czasami (całkiem często właściwie) to „menedżer grupy” to zrobił

Mieliśmy specjalny sprzęt dedykowany do tego (jeden Intel i jeden IBM / AIX), który był niskiej specyfikacji dla wszystkiego oprócz miejsca na dysku, ponieważ nie musieliśmy uruchamiać niczego na przywróconym hoście.

Pierwsze kilka rund było dość pracochłonne, ale doprowadziło nas do usprawnienia procesu przywracania, który jest ważną częścią tworzenia kopii zapasowych.

Ponieważ wydaje się, że masz na myśli fakt, że administrator nie zauważa, że ​​zadanie tworzenia kopii zapasowej „pęka”, a nie tyle, że działająca kopia zapasowa nie działała prawidłowo, sugerowałbym zbudowanie pewnego rodzaju skryptów monitorujących wokół kopii zapasowych.

Budując domowe rozwiązanie do tworzenia kopii zapasowych, zrobiłbym coś takiego:

• Zbuduj skrypt do tworzenia kopii zapasowych danych.
• Wykonaj przywracanie testu, aby upewnić się, że skrypt działa poprawnie.
• W skrypcie lub za pomocą innych środków zaimplementuj sposób śledzenia stanu kopii zapasowych (sukces, niepowodzenie, uruchomiono, nie uruchomiono).
• Monitoruj status śledzenia (e-mail, baza danych, coś)

Po tym wszystkim wszystko powinno być w porządku. Jedną dodatkową rzeczą do zrobienia byłoby regularne przywracanie testów. Jeśli masz dodatkowy sprzęt, aby przekazać darowiznę na ten cel.

Tam, gdzie pracuję, mamy ciepłą witrynę, raz w miesiącu losowo wybieramy system lub bazę danych i przechodzimy do naszej ciepłej strony i przeprowadzamy testowe przywracanie na gołym metalu, aby zapewnić możliwość odzyskania danych.

Szczerze mówiąc, jeśli Twoje dane są dla Ciebie bardzo ważne, w twoim najlepszym interesie byłoby zainwestowanie w oprogramowanie do zarządzania Twoimi kopiami zapasowymi. Istnieją setki produktów do tego, od taniego i prostego do klasy korporacyjnej.

Jeśli korzystasz z zestawu odręcznych skryptów uruchomionych w pliku crontab dla kopii zapasowych firm, prędzej czy później prawdopodobnie zostaniesz spalony.

Posiadamy 60-procentowe wersje „referencyjnych” wersji naszych systemów „produkcyjnych”, używamy ich do końcowego testowania zmian, przywracamy kopie zapasowe „produkcyjne” do tych systemów - testuje kopię zapasową oraz zapewnia, że ​​oba środowiska są ze sobą w zgodzie .

Jednym z podejść jest tworzenie skryptów zadania „odzyskiwania”, które ma być uruchamiane okresowo, na przykład takie, które pobiera określony plik tekstowy z najnowszej kopii zapasowej i wysyła Ci jego zawartość pocztą e-mail. Jeśli to możliwe, należy to - przynajmniej czasami - wykonać przy użyciu innego pola niż to, które utworzyło lub utworzyło kopię zapasową danych, aby upewnić się, że zadziała, jeśli zajdzie taka potrzeba. Zaletą jest to, że możesz mieć pewność, że wszystkie Twoje mechanizmy szyfrowania / deszyfrowania, kompresji i przechowywania działają.

Jest to nieco bardziej zaangażowane w przypadku wyspecjalizowanych kopii zapasowych, takich jak serwery poczty e-mail i bazy danych, chociaż wykonywanie pewnego rodzaju odzyskiwania na małą skalę z małej kopii zapasowej DB lub kopii zapasowej skrzynki pocztowej na poziomie cegły i weryfikacja zawartości jest z pewnością możliwa, tylko trochę bardziej zaangażowana.

Takie podejście nie powinno również zastępować okresowego pełnego przywracania, aby zapewnić odzyskanie danych w nagłych przypadkach - pozwala jedynie być bardziej pewnym co do integralności codziennego zadania tworzenia kopii zapasowych.

Podczas przywracania testowego nie czuję się komfortowo w punkcie „wygląda to ładnie, pliki są przywracane, wygląda na to, że nie brakuje żadnego pliku, nawet rozmiary pasują”, lub w punkcie „to wygląda ładnie, uruchomiłem aplikację. .. nie ulega awarii, wyświetla przyzwoite dane ".

Chcę przywrócić serwer / klaster od zera, a następnie użyć go do produkcji . Nie na minutę, nie na godzinę, ale na stałe . Jeśli twierdzisz, że przywracanie zakończyło się powodzeniem, nie ma absolutnie żadnego powodu, aby nie rozpocząć produkcji. To nie jest jakiś „brudny” system, o którym należy zapomnieć. To system, z którym spotkasz się po prawdziwej katastrofie. Więc jeśli przejdzie etap „wygląda ładnie”, żyj z nim. Wykonaj kopię zapasową następnej nocy. Zapomnij o oryginalnym. Prawdopodobnie będzie odkryć jakieś usterki za pomocą tej metody, i będzie zmuszony do naprawić wszystkie z nich . Kolejne przywrócenie tego samego systemu ma przyzwoitą szansę na odniesienie 100% sukcesu.

Dotyczy to oprogramowania do tworzenia kopii zapasowych i serwera. Tak, musisz je również przywrócić.

Nie masz budżetu na zakup dedykowanego sprzętu do przywracania?

• Zwróć uwagę, że absolutnie potrzebujesz budżetu. Za każdym razem przypominaj decydentom, że ważny test przywracania nie został jeszcze przeprowadzony. (I tak, zbierz dowody, żeby zakryć swój tyłek. Trudny świat.)
• W większości organizacji od czasu do czasu firma potrzebuje migracji jakiegoś systemu na inny sprzęt, więc skorzystaj z okazji. Do migracji zawsze wybieraj metodę „przywróć z kopii zapasowej”, udając, że właśnie zgubiłeś oryginalny sprzęt. Tak, oznacza to więcej przestojów, przepraszam za to. Przynajmniej będziesz mieć pewność, że twoja kopia zapasowa jest przydatna.
• Brak migracji? Być może możesz wypożyczyć sprzęt na dwa tygodnie i wykonać dwa testy przywracania (przywróć pożyczony sprzęt, poczekaj ponad tydzień, przywróć z pożyczonego do oryginalnego, żyj z nim). Zazwyczaj, jeśli zakupiono nowy sprzęt do jakiegoś nowego systemu i właściwie wszystko ułożysz, możesz łatwo go pożyczyć - oferując kompleksowe testowanie na dwa tygodnie. Jeśli nowy sprzęt nie jest w 100% identyczny ze starym, to sprawi, że Twój test będzie jeszcze lepszy. Skąd wiesz, że otrzymasz identyczny sprzęt w przypadku prawdziwej katastrofy?
• W tej chwili wdrażasz jakiś nowy system? Czy możesz teraz przetestować przywracanie? Nie używaj dodatkowego sprzętu, po prostu zastąp nowy system, ponieważ masz świeżą wiedzę, jak szybko go ponownie wdrożyć. Działa to, jeśli nie ma jeszcze istotnych danych. Ponownie przejdź do produkcji przywróconej wersji, a nie do świeżo ponownie zainstalowanej wersji.

1. Ćwiczenia przeciwpożarowe.
2. Zasady testowania wszystkich kopii zapasowych co 6 miesięcy to bardzo dobry pomysł
3. Jeśli chodzi o testowanie, musisz spojrzeć na każdą aplikację lub system, dla którego utworzono kopię zapasową. Idealnie, co stanowi „udaną” lub „możliwą do odzyskania” kopię zapasową, należy wymienić w Opisie usługi lub SOP (dokumentacja operacyjna) dla kopii zapasowej, wraz z innymi szczegółami, takimi jak czas przechowywania, bladibla.

Prawdopodobnie okaże się, że niektóre typy kopii zapasowych można łatwo przetestować pod kątem przywracania za pomocą skryptów (takich jak bazy danych), podczas gdy inne wymagają ręcznego wprowadzania danych (przywracanie Active Directory). Zautomatyzuj maksymalnie, jak to możliwe, upewnij się, że istnieje jakiś rodzaj raportowania i upewnij się, że „ktoś” wykonuje testy ręczne również w regularnych odstępach czasu. Izolowane środowisko (przeskalowana kopia produktu) ułatwi wykonywanie testów przywracania.

Chociaż nie testujemy kopii zapasowych, mamy scentralizowany komponent do sprawdzania i raportowania kopii zapasowych w systemie, który opracowaliśmy BackupRadar.com. Sprawdź, czy to pomaga w tym komponencie. Dołącza kopię wiadomości e-mail o sukcesie / niepowodzeniu do zasad tworzenia kopii zapasowych, a także dołącza zrzuty ekranu, jeśli oprogramowanie do tworzenia kopii zapasowych również je wysyła.

Dzięki, Patrick

Upewnij się, że rejestrowane jest działanie tworzenia kopii zapasowych, a następnie napisz coś (oczywiście w perlu), który analizuje dzienniki szukające błędów, destyluj i wysyłaj jako codzienny e-mail.