Scentralizowany Backup & DR w środowisku multi-hypervisor — case study
Jak zaprojektowaliśmy i wdrożyliśmy infrastrukturę Veeam Backup & Replication dla trzech hypervisorów (VMware, Hyper-V, oVirt) z offsite do Azure i ochroną przed ransomware.
Trzy hypervisory. VMware ESXi, Microsoft Hyper-V i oVirt. Rozproszone kopie zapasowe. Zero spójnej strategii ochrony danych. Tak wyglądała rzeczywistość klienta, który potrzebował jednego, scentralizowanego systemu backupu zgodnego z zasadą 3-2-1 — i odpornego na ransomware.
📋 TL;DR
- Stan zastany: trzy różne platformy wirtualizacyjne, brak spójnej strategii backupu, brak offsite
- Rozwiązanie: 3× Veeam Backup & Replication (instancja per hypervisor) + Scale-Out Backup Repository + Azure Blob Storage (Capacity Tier)
- Bezpieczeństwo: Object Lock w Azure — kopie niemodyfikowalne, odporne na ransomware
- Efekt: RPO/RTO skrócone do minut, koszty zoptymalizowane przez deduplikację i tiering, pełna zgodność z zasadą 3-2-1
⚠️ Problem: trzy hypervisory, zero spójności
Organizacja rozwijała się dynamicznie i w różnych momentach wdrażała różne technologie wirtualizacyjne. Efekt? Środowisko produkcyjne działające na trzech niezależnych platformach:
| Platforma | Zastosowanie | Mechanizm migawkowy |
|---|---|---|
| VMware ESXi | Główne środowiska produkcyjne | vSphere Snapshots + HotAdd |
| Microsoft Hyper-V | Aplikacje Windows, serwery AD | VSS (Volume Shadow Copy) |
| oVirt | Wewnętrzne środowiska deweloperskie | oVirt API Snapshots |
Każda platforma miała własne, niezależne podejście do backupu — lub nie miała go wcale. Brakowało centralnego repozytorium, brakowało kopii offsite, brakowało gwarancji niezmienności danych. Pytanie „co się stanie, jeśli padnie całe DC?” nie miało dobrej odpowiedzi.
Co wymagało rozwiązania?
- Brak strategii 3-2-1 — kopie zapasowe istniały lokalnie, bez offsite
- Niespójna ochrona — każdy hypervisor był „backupowany” inaczej (lub wcale)
- Brak immutability — ransomware mógłby zaszyfrować również kopie zapasowe
- Długi czas odtwarzania — brak testowanych procedur DR
- Koszty przechowywania — brak deduplikacji, brak tieringu
🎯 Cel projektu
Wymagania były jasne:
- Spójna ochrona wszystkich trzech platform wirtualizacyjnych z jednego ekosystemu
- Zasada 3-2-1 — minimum 3 kopie, na 2 różnych nośnikach, 1 kopia offsite
- Niezmienność kopii zapasowych — ochrona przed ransomware i przypadkowym usunięciem
- Optymalizacja RPO/RTO — krytyczne usługi przywracane w minutach, nie godzinach
- Kontrola kosztów — inteligentne zarządzanie przestrzenią dyskową
🔧 Rozwiązanie: architektura krok po kroku
Krok 1: Trzy instancje Veeam — natywne wsparcie per hypervisor
Jako certyfikowany inżynier Veeam VMCE, zaprojektowałem architekturę opartą na trzech dedykowanych instancjach Veeam Backup & Replication. Każda została zoptymalizowana pod konkretny hypervisor, żeby w pełni wykorzystać natywne mechanizmy migawkowe i zminimalizować okna backupowe.
┌──────────────────────────────────────────────────────────────┐
│ VEEAM INFRASTRUCTURE │
│ │
│ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │
│ │ VBR #1 │ │ VBR #2 │ │ VBR #3 │ │
│ │ VMware ESXi │ │ Hyper-V │ │ oVirt │ │
│ │ │ │ │ │ │ │
│ │ • HotAdd │ │ • VSS │ │ • Veeam │ │
│ │ • CBT │ │ • Application │ │ Kasten / │ │
│ │ • vSphere API │ │ Consistent │ │ Plug-in │ │
│ └───────┬────────┘ └───────┬────────┘ └───────┬────────┘ │
│ │ │ │ │
│ └──────────────────┼──────────────────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ SOBR │ │
│ │ Scale-Out │ │
│ │ Backup Repo │ │
│ ├─────────────────┤ │
│ │ Performance │ │
│ │ Tier (lokalne) │──── szybki restore │
│ ├─────────────────┤ │
│ │ Capacity Tier │ │
│ │ (Azure Blob) │──── offsite + 3-2-1 │
│ │ + Object Lock │──── immutability │
│ └─────────────────┘ │
└──────────────────────────────────────────────────────────────┘Instancja VMware ESXi — skonfigurowana z mechanizmem HotAdd dla maksymalnej wydajności przesyłu danych. Changed Block Tracking (CBT) zapewnia przyrostowe kopie zapasowe bez pełnego skanowania dysków.
Instancja Hyper-V — zintegrowana z usługami VSS (Volume Shadow Copy Service) dla spójności aplikacyjnej systemów Windows. Krytyczne dla środowisk z Active Directory i bazami SQL Server.
Instancja oVirt — z wykorzystaniem Veeam Kasten / Plug-in zapewniającego pełną ochronę maszyn wirtualnych na tej platformie. Natywna integracja z API oVirt gwarantuje konsystentne snapshoty.
Krok 2: Scale-Out Backup Repository z Azure Capacity Tier
Kluczowym elementem architektury było wdrożenie Scale-Out Backup Repository (SOBR) łączącego dwa poziomy przechowywania:
| Tier | Rola | Technologia |
|---|---|---|
| Performance Tier | Szybki dostęp do najnowszych kopii | Lokalne repozytorium (dyski NVMe/SSD) |
| Capacity Tier | Długoterminowe przechowywanie + offsite | Azure Blob Storage |
Dane automatycznie migrują z Performance Tier do Capacity Tier zgodnie z politykami retencji. Najnowsze kopie pozostają lokalnie — dla natychmiastowego odtwarzania. Starsze kopie trafiają do Azure — dla zgodności z zasadą 3-2-1 i ochrony przed utratą całego data center.
Krok 3: Object Lock — niezmienność kopii zapasowych
Ostatni, ale kluczowy element: Object Lock w Azure Blob Storage. Ta funkcja sprawia, że kopie zapasowe w Cloud Tier są:
- Niemodyfikowalne — nie można ich zmienić ani nadpisać
- Nieusuwalne — nie można ich skasować przed upływem okresu retencji
- Odporne na ransomware — nawet jeśli atakujący przejmie dostęp do infrastruktury backupowej, kopie w Azure pozostają nietknięte
To jest różnica między „mamy backup” a „mamy backup, który przetrwa atak”.
📊 Rezultaty
| Metryka | Przed | Po wdrożeniu |
|---|---|---|
| RPO (Recovery Point Objective) | Nieregularne, często >24h | Zdefiniowane per workload (od 1h do 4h) |
| RTO (Recovery Time Objective) | Godziny (ręczne odtwarzanie) | Kilkanaście minut (Instant Recovery) |
| Zasada 3-2-1 | ❌ Niespełniona | ✅ Pełna zgodność |
| Ochrona przed ransomware | ❌ Brak | ✅ Object Lock + immutability |
| Koszty przechowywania | Wysokie (brak deduplikacji) | Zoptymalizowane (deduplikacja + tiering) |
| Spójność ochrony | 3 różne podejścia | 1 ekosystem Veeam |
Optymalizacja RPO i RTO
Dzięki konfiguracji opartej na dobrych praktykach VMCE, czas przywracania krytycznych usług spadł do kilkunastu minut. Mechanizm Instant Recovery pozwala uruchomić maszynę wirtualną bezpośrednio z backupu — bez oczekiwania na pełny restore na docelowy storage.
Redukcja kosztów
Deduplikacja i kompresja Veeam w połączeniu z tieringiem do Azure pozwoliły na:
- Optymalne wykorzystanie lokalnej przestrzeni dyskowej (tylko najnowsze kopie)
- Obniżenie kosztów przechowywania danych długoterminowych (Azure Cool/Archive)
- Eliminację nadmiarowej infrastruktury backupowej
Ochrona przed ransomware
Object Lock w Azure to ostatnia linia obrony. Nawet w scenariuszu pełnego kompromisu środowiska on-premises — zaszyfrowane serwery, skasowane lokalne kopie — kopie w Cloud Tier pozostają nienaruszone i gotowe do odtworzenia.
🔑 Kluczowe wnioski
- Multi-hypervisor nie oznacza multi-chaos — z odpowiednią architekturą można spójnie chronić nawet wysoce heterogeniczne środowiska
- Zasada 3-2-1 to minimum, nie luksus — offsite w chmurze publicznej eliminuje ryzyko utraty danych przy awarii DC
- Immutability to must-have — w dobie ransomware kopie zapasowe bez ochrony przed modyfikacją to kopie zapasowe, które mogą nie istnieć, gdy ich potrzebujesz
- Certyfikacja ma znaczenie — wiedza VMCE pozwala wycisnąć z Veeam maksimum wydajności i bezpieczeństwa
Potrzebujesz scentralizowanego backupu w środowisku z wieloma hypervisorami? Jako partner Veeam VCSP projektujemy i wdrażamy infrastrukturę backupową dopasowaną do Twojej architektury — VMware, Hyper-V, oVirt czy Proxmox. Porozmawiajmy →