Aby ograniczyć skutki awarii dysku serwera bazy danych, należy przede wszystkim
A. instalować najnowszą wersję serwera
B. prowadzić pełną listę użytkowników serwera
C. opisać strukturę danych w tabelach
D. regularnie wykonywać kopie zapasowe na innym nośniku
Najważniejszym sposobem ograniczenia skutków awarii dysku serwera bazy danych jest regularne wykonywanie kopii zapasowych na innym nośniku. Chodzi o to, że uszkodzenie dysku może oznaczać utratę plików bazy, dzienników transakcyjnych, konfiguracji serwera albo nawet całego systemu. Jeśli kopia znajduje się na tym samym dysku, to w praktyce znika razem z awarią, więc niewiele pomaga. Dlatego w dobrych praktykach administracyjnych stosuje się zasadę 3-2-1: trzy kopie danych, na dwóch różnych typach nośników, z jedną kopią poza główną lokalizacją. Moim zdaniem to jedna z tych zasad, które brzmią nudno, ale ratują skórę w realnej pracy. W przypadku baz danych ważne są nie tylko pełne backupy, ale też kopie przyrostowe, różnicowe i backup logów transakcyjnych, bo pozwalają odtworzyć dane z konkretnego momentu. Dobrze jest też testować odtwarzanie kopii, bo backup, którego nikt nigdy nie sprawdził, jest trochę jak gaśnica bez przeglądu. W praktyce administrator powinien ustalić harmonogram, miejsce przechowywania kopii, retencję oraz procedurę przywracania po awarii.
W tym pytaniu łatwo pomylić działania administracyjne, które ogólnie są sensowne, z działaniami realnie ograniczającymi skutki awarii dysku. Instalowanie najnowszej wersji serwera bazy danych może poprawić bezpieczeństwo, wydajność i zgodność z aktualnymi standardami, ale samo w sobie nie zabezpiecza danych przed fizycznym uszkodzeniem nośnika. Aktualizacja nie sprawi, że utracone pliki bazy magicznie wrócą. Z mojego doświadczenia wynika, że to częsty błąd myślowy: skoro coś jest dobrą praktyką, to pewnie rozwiązuje każdy problem. A tutaj problemem jest utrata danych po awarii sprzętu. Prowadzenie listy użytkowników serwera też jest przydatne, szczególnie przy audycie, kontroli dostępu i zarządzaniu uprawnieniami. Pomaga ustalić, kto ma dostęp do zasobów, ale nie odtworzy tabel, rekordów ani konfiguracji po uszkodzeniu dysku. Podobnie opisanie struktury danych w tabelach, czyli dokumentacja schematu, jest ważne dla programistów i administratorów, bo ułatwia rozwój systemu oraz analizę relacji między tabelami. Jednak dokumentacja struktury nie zastępuje kopii samej bazy. Można wiedzieć, że tabela miała kolumny id, login i data_utworzenia, ale bez backupu nie odzyska się konkretnych wpisów klientów, zamówień czy logów. W administracji bazami danych podstawą ochrony przed awarią nośnika są kopie zapasowe przechowywane poza uszkodzonym środowiskiem oraz regularne testy przywracania. Dopiero wtedy mówimy o sensownym planie odtwarzania po awarii, a nie tylko o porządku w dokumentach czy aktualnym oprogramowaniu.