RAID nie jest kopią zapasową.
Dlaczego ten mit nadal jest groźny?

„Mamy RAID, więc dane są bezpieczne" to jedno z najczęstszych i najbardziej niebezpiecznych uproszczeń dotyczących infrastruktury IT.

Macierz RAID rzeczywiście zwiększa odporność serwera na awarię jednego lub kilku dysków. W zależności od konfiguracji może również poprawić wydajność zapisu i odczytu danych. Nie chroni jednak przed usunięciem pliku, ransomware, błędem aplikacji, awarią całego serwera, pożarem ani utratą lokalizacji.

RAID i backup rozwiązują dwa zupełnie różne problemy. RAID ma utrzymać działanie systemu po awarii nośnika. Backup ma umożliwić odzyskanie danych po ich utracie, uszkodzeniu lub niepożądanej zmianie.

Firma potrzebuje obu tych mechanizmów, ale nie powinna traktować jednego jako zamiennika drugiego.

Czym jest RAID?

RAID, czyli Redundant Array of Independent Disks, to sposób łączenia kilku dysków w jeden logiczny zasób. W zależności od wybranego poziomu dane są kopiowane na kilka dysków, rozdzielane pomiędzy nośniki lub chronione za pomocą informacji o parzystości.

Najważniejszym celem RAID jest ograniczenie skutków awarii dysku. Jeżeli jeden nośnik przestanie działać, system może nadal pracować, a administrator otrzymuje czas na wymianę uszkodzonego elementu i odbudowę macierzy.

Najpopularniejsze poziomy RAID

Żaden poziom nie jest automatycznie najlepszy dla każdego serwera. Wybór powinien uwzględniać rodzaj danych, obciążenie, pojemność, liczbę dysków, akceptowalny czas odbudowy i budżet.

RAID chroni dostępność, a backup chroni dane

RAID może sprawić, że użytkownicy nie zauważą awarii jednego dysku. Backup pozwala wrócić do poprzedniej wersji danych albo odtworzyć cały system po poważniejszym incydencie.

Dlaczego RAID nie jest backupem?

RAID nie przechowuje historii danych

Macierz przechowuje bieżący stan plików. Jeżeli użytkownik usunie dokument, operacja zostanie wykonana na całej macierzy. Jeżeli aplikacja nadpisze poprawne dane błędną wersją, RAID zapisze nowy stan na wszystkich nośnikach.

Nie ma możliwości powrotu do wersji sprzed godziny, dnia, tygodnia, aktualizacji ani błędnej operacji. Do tego potrzebne są punkty przywracania, snapshoty oraz backup.

RAID nie chroni przed ransomware

Ransomware działa na poziomie plików, udziałów sieciowych, aplikacji lub całych systemów. Jeżeli zaszyfruje plik na wolumenie RAID, zaszyfrowana wersja zostanie poprawnie zapisana na wszystkich dyskach macierzy.

Z punktu widzenia kontrolera RAID nie jest to awaria. System otrzymał prawidłowe polecenie zapisu i wykonał je zgodnie z projektem. RAID nie potrafi rozpoznać, że zmiana została wykonana przez złośliwe oprogramowanie.

RAID nie chroni przed przypadkowym usunięciem

Administrator może usunąć maszynę wirtualną, skasować katalog, wykonać błędne polecenie, sformatować wolumen albo usunąć niewłaściwą bazę danych. RAID powtórzy tę operację na wszystkich swoich elementach. Redundancja dysków nie zabezpiecza przed błędem osoby mającej dostęp do systemu.

RAID nie chroni przed uszkodzeniem logicznym

Uszkodzenie systemu plików, błędny zapis aplikacji, korupcja bazy danych, nieudana aktualizacja czy wadliwy sterownik - macierz może być całkowicie sprawna technicznie, a dane mogą być bezużyteczne. RAID chroni przed awarią nośnika, ale nie ocenia poprawności przechowywanej zawartości.

RAID nie chroni przed awarią całego serwera

Dyski są tylko jednym z elementów infrastruktury. Awarii mogą ulec również kontroler RAID, płyta główna, procesor, pamięć, zasilacz, backplane, okablowanie czy firmware. W niektórych przypadkach awaria kontrolera lub błędna aktualizacja firmware może wpłynąć na dostęp do całej macierzy.

Backup powinien być możliwy do odtworzenia na innym sprzęcie, a nie zależeć od jednego serwera.

RAID nie chroni przed utratą lokalizacji

Jeżeli serwer i wszystkie jego dyski znajdują się w jednym pomieszczeniu, nadal są narażone na pożar, zalanie, kradzież, przepięcie i awarię zasilania. Macierz z sześcioma dyskami stojąca w jednym budynku nadal jest jednym zasobem w jednej lokalizacji. Dlatego przynajmniej jedna kopia powinna znajdować się poza główną serwerownią.

RAID nie chroni przed błędną konfiguracją

RAID może działać przez wiele lat, mimo że jego konfiguracja zawiera ukryte ryzyko:

Firma może uważać, że posiada redundancję, podczas gdy jeden dysk nie działa od kilku miesięcy.

Odbudowa RAID nie jest neutralną operacją

Po wymianie uszkodzonego dysku macierz rozpoczyna rebuild. Podczas odbudowy wszystkie pozostałe nośniki są intensywnie odczytywane. Operacja może trwać wiele godzin lub dni, obniżać wydajność, ujawnić kolejne uszkodzenia albo zakończyć się błędem.

Ryzyko zależy od rodzaju RAID, pojemności i wieku dysków, obciążenia produkcyjnego oraz stanu pozostałych nośników. RAID 6 ogranicza ryzyko utraty macierzy po awarii drugiego dysku, ale nie eliminuje wszystkich możliwych problemów.

Dlatego przed rozpoczęciem odbudowy szczególnie ważne jest posiadanie aktualnego i sprawdzonego backupu.

RAID nie daje kopii niezależnej od produkcji

Dyski w macierzy są częścią tego samego systemu produkcyjnego. Mają wspólne zasilanie, kontroler, obudowę, środowisko, system operacyjny i uprawnienia administracyjne. Nie są więc niezależnymi kopiami w rozumieniu strategii backupowej.

Dwa dyski RAID 1 nie oznaczają dwóch backupów. To jedna macierz składająca się z dwóch nośników.

Snapshot też nie zawsze jest backupem

Snapshot może umożliwić szybki powrót do wcześniejszego stanu wolumenu lub maszyny wirtualnej. Jest bardzo przydatny przed aktualizacją, zmianą konfiguracji albo testem.

Jeżeli snapshot znajduje się jednak na tym samym storage, może zostać utracony razem z produkcją. Nie chroni również przed utratą całego serwera, lokalizacji albo przejęciem konta administratora. Snapshot powinien uzupełniać backup, a nie go zastępować.

Skąd bierze się mit, że RAID jest backupem?

Najczęstszą przyczyną jest pomieszanie dwóch pojęć: redundancji i kopii zapasowej. Użytkownik widzi kilka dysków z tymi samymi danymi i zakłada, że posiada kilka kopii. Technicznie dane rzeczywiście znajdują się na wielu nośnikach - wszystkie są jednak częścią jednego systemu, przechowują ten sam aktualny stan i są narażone na te same zagrożenia logiczne.

Mit jest również wzmacniany przez fakt, że RAID często skutecznie chroni przed najczęstszą awarią sprzętową, czyli uszkodzeniem pojedynczego dysku. Po kilku takich zdarzeniach firma może uznać, że jest zabezpieczona przed utratą danych w ogóle. Problem ujawnia się dopiero przy incydencie, którego RAID nie został zaprojektowany obsługiwać.

RAID, replikacja i backup to różne warstwy ochrony

Dojrzała strategia może wykorzystywać wszystkie te warstwy jednocześnie.

Reguła 3-2-1-1-0

Popularnym punktem wyjścia jest zasada 3-2-1-1-0:

RAID może być elementem infrastruktury produkcyjnej albo repozytorium backupowego, ale sam nie spełnia tej zasady. Przykładowa konfiguracja:

1. 1 dane produkcyjne na macierzy RAID,
2. 2 lokalny backup na oddzielnym serwerze,
3. 3 kopia off-site w drugiej lokalizacji,
4. 4 dodatkowa warstwa odporna na modyfikację,
5. 5 regularny test restore.

Jak powinna wyglądać skuteczna ochrona danych?

1. 1 Redundancja produkcji: RAID, ZFS mirror lub RAIDZ, Ceph, replikacja storage, klaster HA. Celem jest ograniczenie przestojów po awarii sprzętowej - to jeszcze nie backup.
2. 2 Lokalny backup: kopia na oddzielnym storage, niezależnym od produkcji: Proxmox Backup Server, Veeam, dedykowany NAS backupowy, BorgBackup lub Restic. Zapewnia szybki restore pliku, bazy lub całego serwera.
3. 3 Backup off-site: kopia w drugim Data Center, innej lokalizacji lub zabezpieczonej chmurze, z oddzielnymi danymi uwierzytelniającymi, własną retencją i monitoringiem. Sama synchronizacja katalogu nie wystarczy, jeżeli usunięcia są natychmiast replikowane.
4. 4 Ochrona przed modyfikacją: przynajmniej jedna kopia trudna do usunięcia nawet po przejęciu głównego środowiska: Object Lock, repozytorium immutable, taśma, kopia offline lub WORM.
5. 5 Monitoring: status zadań, czas ostatniej udanej kopii, zgodność z RPO, wolne miejsce, retencja, synchronizacja off-site, stan dysków i wyniki testów. Backup bez monitoringu może przestać działać na długo przed pierwszym alertem biznesowym.
6. 6 Testy restore: odzyskanie pliku, restore bazy, uruchomienie maszyny wirtualnej, sprawdzenie aplikacji, scenariusz DR. Dla systemów krytycznych test raz na kwartał jest rozsądnym punktem wyjścia.

Jak zbudować monitoring całego łańcucha, opisaliśmy w artykule Jak monitorować backupy?

Czy NAS z RAID jest backupem?

Może być elementem backupu, ale nie dlatego, że posiada RAID.

Dlaczego backup wyłącznie na NAS-ie to za mało, opisaliśmy szerzej w osobnym artykule.

Czy replikacja serwera wystarczy?

Replikacja zwiększa dostępność i może skrócić czas powrotu po awarii hosta. Nie chroni jednak automatycznie przed błędnym usunięciem, ransomware, korupcją bazy ani przejęciem administratora. Uszkodzony stan może zostać szybko przesłany na drugi serwer. Replikacja i backup powinny działać obok siebie.

Jak dobrać poziom RAID?

Nie istnieje jedna odpowiedź dobra dla wszystkich środowisk:

• -RAID 1 może wystarczyć przy niewielkiej liczbie dysków, umiarkowanym obciążeniu i prostych wymaganiach,
• -RAID 10 warto rozważyć przy bazach danych, niskich wymaganych opóźnieniach i wielu operacjach losowych,
• -RAID 6 może mieć sens przy wielu dużych dyskach, gdy ważna jest pojemność i odporność na awarię dwóch nośników,
• -ZFS lub Ceph mogą być lepsze przy klastrach, potrzebie kontroli integralności i rozproszonym storage.

Dobór RAID powinien być częścią projektu infrastruktury, a nie zamiennikiem strategii backupowej.

Najczęstsze błędy związane z RAID i backupem

Kopia znajdująca się na innym katalogu tego samego storage zniknie razem z produkcją przy awarii macierzy. A repozytorium dostępne z tych samych kont co produkcja może zostać zaszyfrowane razem z nią - jak temu zapobiec, opisaliśmy w artykule Czy Twoje backupy przetrwają ransomware?

Jak sprawdzić, czy firma ma backup, a nie tylko RAID?

Warto odpowiedzieć na kilka pytań:

1. 1 Czy możemy odzyskać plik usunięty miesiąc temu?
2. 2 Czy istnieje kopia poza główną lokalizacją?
3. 3 Czy ransomware z konta administratora może usunąć backup?
4. 4 Czy backup znajduje się na innym urządzeniu niż dane produkcyjne?
5. 5 Czy znamy czas ostatniego udanego backupu?
6. 6 Czy potrafimy odtworzyć bazę do konkretnego punktu?
7. 7 Kiedy ostatnio wykonywaliśmy test restore?
8. 8 Czy znamy rzeczywiste RPO i RTO?
9. 9 Czy utrata całego serwera oznacza utratę wszystkich danych?
10. 10 Czy ktoś otrzyma alert po awarii dysku?

Jeżeli odpowiedzi są niejasne, firma prawdopodobnie posiada redundancję, ale niepełną strategię backupową.

Przykładowe architektury

Architektura powinna wynikać z kosztu przestoju i dopuszczalnej utraty danych.

Podsumowanie

RAID jest bardzo ważnym elementem infrastruktury. Zwiększa odporność serwera na awarie dysków i może ograniczyć liczbę przestojów. Nie zapewnia jednak historii wersji, ochrony przed usunięciem i ransomware, kopii poza lokalizacją, odtworzenia po awarii całego serwera ani procedury Disaster Recovery.

RAID pomaga utrzymać system przy życiu, a backup pozwala odzyskać dane, gdy system albo dane zostaną utracone.

Dojrzała strategia powinna łączyć redundancję, lokalny backup, kopię off-site, ochronę przed modyfikacją, monitoring i regularne testy restore.

W PRO-Admin nie oceniamy ochrony danych wyłącznie na podstawie liczby dysków w serwerze. Sprawdzamy cały łańcuch: produkcję, RAID, backup lokalny, kopię zdalną, uprawnienia, retencję, monitoring oraz realną możliwość odtworzenia systemu. Dopiero wtedy można uczciwie powiedzieć, że dane firmy są zabezpieczone.