Backup i disaster recovery w chmurze: przewodnik multi-cloud
Snapshot to nie backup. Backup to nie plan na disaster recovery. Te dwa zdania to cały powód, dla którego ten przewodnik istnieje. Większość deklaracji “mamy backupy” rozpada się pod jednym pytaniem: kiedy ostatnio przywracałeś któryś i ile czasu to zajęło? To praktyczny przegląd tego, jak myśleć o problemie, zanim wybierzesz narzędzie.
Backup kontra disaster recovery: różnica, która ma znaczenie
- Backup to kopia danych którą możesz przywrócić. Adresuje tylko sytuacje utraty danych i koniguracji. Definiuje czy i skąd można je przywrócić.
- Disaster recovery to plan i zdolność do przywrócenia całego środowiska do stanu działania po poważnej awarii. Adresuje sytuację gdy region, datacenter lub konto zostało utracone i trzeba jak najszybciej przywrócić zdolności operacyjne firmy?
Backup to część składowa DR. Możesz mieć idealne backupy i żadnego disaster recovery, bo przywracanie 40 TB przez odbudowaną sieć bez planu oraz runbooka może potrwać wiele dni. W dalszej części przewodnika opisujemy jak świadomie tych narzędzi i procedur korzystać.
Pojęcia, które napędzają każdą decyzję
| Pojęcie | Co znaczy | Jak napędza projekt |
|---|---|---|
| RTO (Recovery Time Objective) | Jak długo możesz być offline | Niskie RTO zmusza do zastosowania "ciepłych" środowisk stadby, w miejsce "zimnego" restore |
| RPO (Recovery Point Objective) | Ile danych możesz stracić (luka od ostatniej dobrej kopii) | Niskie RPO skłaia ku opcjom ciągłej replikacji, w miejsce nocnych snapshotów |
| Zasada 3-2-1 | 3 kopie, na 2 typach nośników, 1 poza lokalizacją (najlepiej 1 niezmienna) | Podstawa przeżywająca awarię pojedynczej lokalizacji lub konta |
| Niezmienność | Backupy, których nie da się zmienić ani usunąć przez ustalony czas (WORM) | Jedyna kontrola, która faktycznie pokonuje ransomware |
| Gorąca kontra zimna | Standby działający (gorący) kontra uruchamiany na żądanie (zimny) | Gorący = szybki i drogi; zimny = tani i wolny. Dopasuj do RTO |
Wszystko dalej (która usługa, ile replikacji, ile wydajesz) wynika z liczb RTO/RPO w Twoim SLA. Ustal je najpierw. Obciążenie tolerujące 24-godzinne RTO i 24-godzinne RPO ma zupełnie inny, dużo tańszy projekt niż takie, które potrzebuje przywracania w ciągu minut.
Spektrum strategii DR
Czterostopniowy model AWS to najprostszy sposób myślenia o kompromisie koszt/szybkość i stosuje się do każdej chmury:
- Backup and restore - najtańsze, najwolniejsze. Przywracanie z backupów do odbudowanego środowiska. RTO od godzin do dni. W porządku dla obciążeń niekrytycznych.
- Pilot light - minimalny rdzeń (bazy replikujące, obrazy gotowe) trzymany ciepło; skalowanie w górę przy awarii. RTO w dziesiątkach minut.
- Warm standby - zmniejszona, ale działająca kopia środowiska; skalowanie w górę przy przełączeniu. RTO w minutach.
- Multi-site active/active - pełna pojemność działająca w dwóch lub więcej lokalizacjach. RTO/RPO bliskie zeru, najwyższy koszt.
Większość organizacji potrzebuje różnych stopni dla różnych obciążeń: active/active dla ścieżki płatności, backup-and-restore dla wewnętrznej wiki. Wybór jednego stopnia dla wszystkiego to sposób, by albo przepłacić lub zaniżyć standard.
Nie masz pewności, czy Twoje cele RTO/RPO pasują do faktycznego DR?
Umów bezpłatną rozmowę 30 min
Natywne opcje, dostawca po dostawcy
Zasady są uniwersalne; narzędzia się różnią. To faktyczna sytuacja u dostawców, których narzędzia firmy faktycznie używają.
| Dostawca | Backup | Disaster recovery |
|---|---|---|
| AWS | AWS Backup (centralne plany, niezmienność Vault Lock, cross-region/cross-account) | AWS Elastic Disaster Recovery (DRS) dla DR na poziomie serwera; Aurora Global Database, replikacja cross-region |
| Azure | Azure Backup (Recovery Services / Backup vaults, immutable vaults) | Azure Site Recovery (ASR) dla replikacji i przełączania VM |
| GCP | Backup and DR Service, snapshoty dysków trwałych | Zasoby regionalne/multi-regionalne, replikacja cross-region |
| OVHcloud | Backup oparty na Veeam, snapshoty, object storage | Replikacja między datacenter; często w parze z Veeam lub Zerto |
| DigitalOcean | Backupy Dropletów, snapshoty wolumenów, Spaces | Snapshot-and-restore; DR zwykle budowane z narzędziami third-party |
| On-prem | Veeam, Commvault, Bacula; taśma/dysk | Replikacja do drugiej lokalizacji lub do chmury jako celu DR |
Dwie uwagi warte wymienienia. Hyperscalery (AWS, Azure, GCP) mają najgłębsze natywne narzędzia backup/DR; AWS Backup i Elastic Disaster Recovery oraz Azure Backup z Site Recovery są najbardziej kompletne. OVH i DigitalOcean pokrywają podstawy natywnie (snapshoty, backupy, object storage), ale DR wykraczające poza snapshot-and-restore buduje się zwykle narzędziami third-party, takimi jak Veeam czy Zerto, albo używając hyperscalera jako celu odzyskania. Dla porównania dwóch największych zobacz nasze dedykowane porównanie Azure Backup vs AWS Backup.
Niezmienność i ransomware: część, której nie wolno pomijać
Ransomware zmienił model zagrożeń backupu. Atakujący celują teraz najpierw w backupy, bo ofiara z działającymi backupami nie płaci. Obroną jest niezmienność: backupy zapisane raz, niezmienialne i nieusuwalne przez zdefiniowany czas, najlepiej w koncie lub lokalizacji, do której poświadczenia produkcyjne nie sięgają.
- AWS: Vault Lock w trybie compliance (nawet root nie usunie do upływu retencji) plus backup cross-account.
- Azure: immutable vaults z soft delete włączonym domyślnie.
- On-prem/inne: niezmienne repozytoria Veeam, object-lock na storage zgodnym z S3.
Jeśli masz wynieść z tego przewodnika jedną rzecz: niezmienna, składowana poza główną lokalizacją, przetestowana kopia to różnica między złym tygodniem a zdarzeniem egzystencjalnym. Reszta to optymalizacja.
Kiedy DRaaS ma sens
Disaster recovery as a service (DRaaS) oddaje replikację, orkiestrację i przełączanie zarządzanemu dostawcy. To właściwy wybór, gdy:
- Brakuje Ci wewnętrznego zespołu, by zbudować i (co kluczowe) przetestować konfigurację DR.
- Potrzebujesz zdefiniowanego RTO/RPO popartego cudzym SLA.
- Twoje środowisko jest on-prem albo na OVH/DigitalOcean i chcesz hyperscalera jako cel odzyskania, nie budując go samodzielnie.
DRaaS nie jest automatycznie tańsze niż DR zarządzane własnymi siłami i dodaje zależność. Ale dla zespołów, których realne ryzyko to “mamy plan DR na papierze, którego nigdy nie przećwiczono”, usługa zarządzana zawierające regularne testy przełączania jest warta więcej niż tańsza konfiguracja, której nikt nie ufa.
Rozsądne podejście domyślne
- Ustal RTO/RPO per klasa obciążenia - nie jedną liczbę dla wszystkiego.
- Zastosuj 3-2-1 z jedną niezmienną, poza lokalizacją kopią - to podstawa.
- Używaj natywnego backupu tam, gdzie żyją obciążenia - AWS Backup, Azure Backup, GCP Backup and DR, cross-region i cross-account domyślnie.
- Dopasuj stopień DR do RTO - backup-and-restore dla długiego ogona, warm standby lub active/active dla ścieżki krytycznej.
- Testuj przywracanie regularnie - nieprzetestowany backup to nadzieja, a nie plan. Wpisz ćwiczenia przełączania do kalendarza.
- Pilnuj kosztu retencji - reguły cyklu życia (lifecycle), by przenosić do tańszych warstw i wygaszać stare punkty odzyskania; zapomniane backupy z długą retencją to cichy koszt.
Jak to pasuje do szerszego obrazu niezawodności, filar Reliability w przeglądzie Well-Architected pokrywa dokładnie te pytania o RTO/RPO i testowanie odzyskiwania.
FAQ
Jaka jest różnica między backupem a disaster recovery? Backup to kopia danych, z której można przywrócić. Disaster recovery to plan i zdolność przywrócenia całego środowiska po poważnej awarii. Backup to jeden wkład do DR; posiadanie backupów to nie to samo co zdolność odzyskania.
Czym są RTO i RPO? RTO (Recovery Time Objective) to jak długo możesz być offline. RPO (Recovery Point Objective) to ile danych możesz stracić. Oba wynikają z Twojego SLA i napędzają cały projekt.
Czym jest zasada backupu 3-2-1? Trzy kopie danych, na dwóch różnych typach nośników, z jedną poza lokalizacją. Nowoczesny dodatek to, że jedna kopia powinna być niezmienna, by przeżyć ransomware.
Czy potrzebuję DRaaS, czy mogę zbudować DR sam? Oba działają. Zbuduj sam, jeśli masz zespół, by to zaprojektować i regularnie testować. Użyj DRaaS, gdy chcesz SLA dostawcy, brakuje Ci wewnętrznej mocy albo chcesz hyperscalera jako cel odzyskania dla obciążeń on-prem/OVH/DigitalOcean, nie budując go.
Jak backupować między wieloma chmurami? Prowadź natywny backup każdej chmury tam, gdzie żyją jej obciążenia, i ustandaryzuj politykę (RTO/RPO, retencja, niezmienność) między nimi, albo użyj narzędzia third-party ze wsparciem cross-cloud. Nie próbuj zmuszać usługi backupu jednej chmury do obciążeń innej.
Podsumowanie
- Backup, DR i przetestowane odzyskiwanie to trzy różne rzeczy. Traktowanie backupu jako planu DR to najczęstszy i najdroższy błąd.
- RTO i RPO napędzają wszystko. Ustal je per klasa obciążenia, potem dopasuj stopień DR (od backup-and-restore po active/active) do każdej.
- Niezmienność to obrona przed ransomware, a testowanie to dowód. Niezmienna, poza lokalizacją, regularnie przywracana kopia to podłoga dla każdego obciążenia, które się liczy.
Jeśli chcesz pomocy w zaprojektowaniu backupu i disaster recovery w AWS, Azure, GCP lub hybrydowym on-prem, zajrzyj do naszych usług backupu i disaster recovery.
Projektujesz backup i disaster recovery?
Umów bezpłatną 30-minutową rozmowę. Pomagamy zespołom ustalić realistyczne cele RTO/RPO, zaprojektować niezmienny backup multi-cloud i prowadzić testy przełączania, które zamieniają dokument DR w zdolność DR.
