Cliffhanger: Kopie zapasowe są w porządku… tutaj… prawda?

W mojej pracy kopie zapasowe mają zaskakująco niski priorytet. Strategia tworzenia kopii zapasowych została wdrożona jakiś czas temu i od tego czasu zakłada się, że kopie zapasowe są w porządku. Jeśli zapytasz sysadminów, powiedzą, że wszystko zostało zapisane.

Ale wtedy, gdy poprosisz o SZCZEGÓLNĄ kopię zapasową, w połowie jej nie ma:

• Dysk się zapełnił
• Taśma nie działa
• Wygląda na to, że ktoś wyłączył zadanie tworzenia kopii zapasowej
• Połączenie sieciowe miało przestoje
• Zamówiliśmy ten dysk wiele lat temu, ale finanse nie zatwierdziły zamówienia
• Pliki są uszkodzone
• Plik zawiera niewłaściwą bazę danych
• Tylko kopie zapasowe dziennika transakcji (bezużyteczne bez pełnego)

Kilka tygodni temu katastrofa zbliżyła się do siebie, ponieważ jeden z serwerów stracił o jeden zbyt wiele dysków RAID. Na szczęście jeden dysk był wystarczająco miły, aby skopiować dane, jeśli próbowałeś wiele razy.

Ale nawet po tej katastrofie nie wydaje mi się, aby przekonać administratorów systemu do poprawy sytuacji. Zastanawiam się więc, jakieś wskazówki dotyczące otwierania ludziom oczu? Wydaje mi się, że idziemy wzdłuż krawędzi urwiska.

Zawsze musisz je naprawić od góry.

Czy obecna strategia tworzenia kopii zapasowych jest wspierana i rozumiana przez kierownictwo? Jeśli nie, jest to bezużyteczne.

Kierownictwo musi wiedzieć o problemach i ryzykach (utracie danych finansowych, które musisz wydać, aby przetrwać, lub danych klientów, których gromadzenie zajęło lata?) I rozważyć to przy podejmowaniu decyzji o działaniach lub podejmowaniu decyzji pozwalając komuś (takiemu jak ty) podjąć działania.

Jeśli nie możesz dostać się do zarządzania, wypróbuj kontrolerów biznesowych lub inne pozycje finansowe, w których odzyskiwanie danych i ich integralność mają duże znaczenie dla raportów firmy. Z kolei w razie potrzeby mogą „rozpocząć burzę” ...

Gdzie zacząć? To katastrofa, która czeka. Podstawową funkcją zadania Sysadmin jest zapewnienie kopii zapasowej danych i ich odzyskania. Wszystko inne jest drugorzędne. Nie, jeśli nie, ale jest.

Oto kilka rzeczy, które możesz zrobić:

1. Śledź KPI dla przywracania. Powinno być możliwe wygenerowanie raportu pokazującego, ile żądań przywrócenia zakończyło się powodzeniem. Wszystko mniej niż 100% powinno zostać dokładnie zbadane. Zarząd kocha raporty, a to jest twardy dowód.

2. Powinny istnieć udokumentowane procedury wszystkich operacji tworzenia kopii zapasowych i przywracania, w tym wszystkich systemów i strategii tworzenia kopii zapasowych, rotacji taśm, harmonogramów, ścieżek eskalacji, przywracania testów itp. Poproś o ich zobaczenie.

3. Porozmawiaj z menadżerem administratorów sys i napisz swoje obawy. Uzbrój się w dowód, że przywracanie nie działa. Jeśli nie ma radości, idź wyżej.

Poważnie - zrób zamieszanie. Takie rzeczy mogą zniszczyć firmę.

Zaproponować (co najmniej) coroczne testy odzyskiwania po awarii. Prace wymagane do pomyślnego wykonania testu powinny ujawnić niedociągnięcia.

Tam, gdzie pracuję, mamy naprawdę dobry dział IT, co roku spotykają się z każdego biura w Europie i organizują „festyn przywracania” na wynajętych serwerach w centrum danych, skutecznie symulując to, co by się stało, gdyby pracownicy przyszli do pracy i znaleźli biuro spłonęło w nocy.

Zaangażuj wielkiego szefa, przypomnij mu, że jeśli dojdzie do katastrofy, nie dostanie premii w tym roku (lub jeszcze gorzej!), Więc może rozsądnie byłoby zorganizować podobne ćwiczenie odzyskiwania po awarii. Nie powinno to zająć dużo czasu i kosztować - administratorzy zostają odesłani ze swoimi zewnętrznymi taśmami kopii zapasowych i proszeni o przyniesienie od nich identycznego środowiska biurowego.

Następnie usiądź i obserwuj, jak IT się poprawia - gdy kierownictwo zda sobie sprawę, że dane firmy są niebezpiecznie bliskie ich trwałej utraty, iskry wylecą (z rakiet, które zostaną strategicznie umieszczone we wspomnianych administratorach)

Łatwo jest obwiniać administratorów - ale Oskar ma rację: te rzeczy są wypychane z góry. Jeśli kierownictwo nie wyda pieniędzy, aby kopie zapasowe stały się priorytetem, sysadmini zwykle nie mają szczęścia i robią, co mogą, wykorzystując posiadane zasoby.

Kluczem do sukcesu jest to, że jesteś jednym z tych pechowych administratorów - a ja byłem w tej łodzi na kilka spotkań z klientami - że upewniasz się, że zarządzanie jest informowane, wielokrotnie i w sposób możliwy do potwierdzenia na papierze, że jest to ryzyko dla biznesu.

Moją strategią jest ciągłe młotkowanie nad problemami. Jeśli to zrobisz, czasem problemy zostaną naprawione, ale głównie po to, aby ktokolwiek, kogo zgłoszę, nie mógł ukryć się za wymówką „nigdy mnie nie poinformowano”. Jako konsultant zwykle mogę pójść lepiej. Mogę zmusić moich szefów do poinformowania wyższej kadry kierowniczej wyższego szczebla niż mogę, że istnieje luka. To rozsiewa winę, a przynajmniej skupia ją na poziomie wyższym niż ja.

Jednocześnie musisz być pomysłowy i ciężko pracować, aby zminimalizować ryzyko przy wszelkich zasobach, które klient może zapewnić.

Podczas gdy w niektórych przypadkach administratorzy mogą być winni, kierownictwo jest zawsze odpowiedzialne: za znajomość ryzyka i niewystarczające działania, aby je złagodzić, lub zatrudnienie ludzi, którzy nie ostrzegają ich przed tymi zagrożeniami.

Odpowiadam za około 200 serwerów rozmieszczonych w północno-zachodniej części Wielkiej Brytanii, i jest to oczywiście zdecydowanie za dużo, aby je sprawdzić ręcznie.

Konfiguruję kopię zapasową, aby po jej zakończeniu uruchomił skrypt (VBScript), który przegląda dziennik kopii zapasowej, sprawdza, czy kopia zapasowa zadziałała, i zapisuje rekord w centralnej bazie danych z wynikiem kopii zapasowej. Następnie w centrali uruchamiam skrypt, który odpytuje tę bazę danych i przedstawia mi listę witryn, w których albo kopia zapasowa zgłosiła błąd, albo nie było raportu z witryny.

Rezultat końcowy jest taki, że kiedy siadam przy biurku, mam listę wszystkich stron, w których muszę sprawdzić kopię zapasową.

Chodzi o to, że domyślnym założeniem jest, że tworzenie kopii zapasowej nie powiodło się, a uważa się, że kopia zapasowa działała tylko wtedy, gdy mój VBScript nie wykrył żadnych błędów i zapisał ten wniosek w mojej bazie danych. Dzięki temu awarie kopii zapasowych nie pozostaną niezauważone.

Niektóre serwery używają Backup Exec, niektóre NTBackup, a niektóre po prostu kopiują swoje pliki na inny serwer w sieci. Nie ma znaczenia, jakiego rodzaju kopie zapasowe wykonują serwery, ponieważ łatwo jest ulepszyć mój VBScript, aby sprawdzić błędy. Mój skrypt jest właściwie dość prosty, po prostu otwiera raport kopii zapasowej jako plik tekstowy i greps dla fraz takich jak „nie udało się zamontować”, „taśma pełna”, „błąd CRC” itp. Jestem pewien, że zrobiłby to profesjonalny programista lepsza praca. Cała sprawa jest jednak prosta i niezawodna, i jest proaktywna w tym sensie, że widzę raport awarii tworzenia kopii zapasowej, czy chcę, czy nie, i nie zauważę błędu, jeśli świadomie zdecyduję się zignorować raport.

JR

PS 99% awarii tworzenia kopii zapasowej wynika z faktu, że użytkownicy zapomnieli zmienić taśmę kopii zapasowej. Czy nie kochasz luserów :-)

Nie testowana kopia zapasowa nie jest kopią zapasową.