Od „ups!” do „spokojnie, mam backup”: Jak Commvault i S3 ratują Ci skórę.

Dane w dzisiejszym świecie to paliwo, bez nich nic nie zadziała. Sprzedaż, księgowość czy systemy IT. Jak więc skutecznie zabezpieczyć infrastrukturę IT, łącząc zaawansowane funkcje systemu Commvault z elastycznością chmury S3? Mamy dla Ciebie praktyczny przewodnik po nowoczesnej architekturze backupu i odzyskiwania danych.

Dane potrafią zaginąć z błahego powodu. Telefon spadnie Ci do toalety podczas scrollowania tiktoka, no nic zdarza się nawet najlepszym. W korpo, gdzie pracujesz może być po prostu awaria dysku w Twoim laptopie albo zwykły błąd admina, który wykasował Twoje dane (spodziewaj się rzeczy niespodziewanych!). Obecnie backup to po prostu dodatkowa kopia danych, która jest trzymana w innym miejscu niż pierwotne dane. Dzięki niemu możesz szybko wrócić do pracy po awarii albo nie będziesz musiał płacić okupu hakerom, którzy wyrządzili Ci krzywdę, a jako firma spełnisz wymagania RODO i audytów. W końcu audytorzy są nieludzcy. Prawda?

źródło: Niebezpiecznik

Najważniejsze jest to, że po prostu zaoszczędzisz kupę kasy i nerwów zamiast odtwarzać dane z „niczego”. Przejdźmy teraz do bardziej technicznych rzeczy, tak na chłopski rozum.

Z jednej strony masz rzeczy do ochrony tj.: zdjęcia z wakacji, dane firmowe, numery kontaktowe do znajomych z liceum. Z drugiej masz miejsce, gdzie to wszystko ląduje. Pamiętaj, ta druga strona zawsze może zawieść. W końcu znikąd się nie wzięło to powiedzenie:

„ludzie dzielą się na tych, którzy robią backupy i na tych, którzy dopiero zaczną je robić”.

Pokażę to bardziej ze strony korporacyjnej na przykładzie Commvault jako systemu backupu.

Z jednej strony: „rzeczy do ochrony” – VM‑ki, serwery plików, bazy, AD, vCenter itd.

Pośrodku: system backupu (u nas Commvault) z Media Agentami. Są to tacy „kurierzy”, którzy odbierają dane od serwerów i wysyłają je na storage.

Z drugiej strony: miejsce, gdzie wszystko ląduje: macierz/NAS/taśmy/S3.

Dla przykładu bierzemy bardzo prostą architekturę w połączeniu z S3 od AWS

Wyjaśnię teraz role:

CommServe/DB to taki mózg, który trzyma konfigurację, historię tasków/jobów/zadań, polityki i harmonogramy.

Media Agent to taki robot od brudnej roboty: zbiera dane, pakuje, deduplikuje, szyfruje i wysyła do magazynu.

Storage jest to docelowe miejsce dla backupu dla nas w tym przypadku jest to S3.

Teraz krótko, dlaczego S3 bardzo fajnie współgra z backupem.

• Skalowalność: jak rosną dane, dokładamy gigabajty/terabajty w S3, a nie kolejną nową macierz.
• Trwałość i dostępnośc danych: S3 składa dane na wiele dysków, więc pojedyncza awaria nie zje kopii.
• Różnej klasy storage: np.: Standard na szybkie odzyski, a Archive na „podkładkę dla audytora”.
• Płacisz za to co używasz: czasami lepsze od kupna dużej macierzy, szczególnie w dzisiejszych czasach, gdzie dyski są bardzo drogie.
• Nie musisz podłączać wyłącznie AWSa, możesz użyć On-premise ECS czy inne chmurowe „S3”.

Teraz bardziej praktycznie, jak Commvault robi backup na S3

1. Konfiguracja bilbioteki
   • zakładamy bucket w S3 (albo dajemy Commvaultowi uprawnienia, żeby zrobił go sam),
   • tworzymy w Commvault „cloud storage” typu Amazon S3 / S3‑compatible,
   • wklejamy endpoint, klucze/role, wybieramy klasę storage i region.
2. Rola Media Agentów:
   • dane od klientów lecą do Media Agenta,
   • Media Agent deduplikuje, kompresuje i robi „wysyłkę” przez API S3,
   • kilka Media Agentów może równolegle wysyłać do tego samego bucketu, robiąc HA i load‑balancing.
3. Lokalny cache (a co to?)
   • opcjonalny „hot tier” na bardzo szybki restore danych
   • dane najpierw wpadają lokalnie, potem są przerzucane do S3 wg polityki (lifecycle/cloud tier),
   • przy odtwarzaniu z ostatnich dni tygodni sięgamy do lokalnego cache, a starsze dane ciągniemy z S3.

Migracja danych z File Servera oraz z Microsoft SharePoint On-Premises do Microsoft SharePoint Online w usłudze M365 – praktyczne wnioski z projektu

Typy backupów w Commvault:

• Full jest to „pełna kopia wszystkiego” prosta, ale ciężka
• Incremental to tylko zmiany od ostatniego backupu. Szybciej, taniej, ale wymaga łańcucha zdarzeń
• Synthetic full dla Commvault składa nowego „fulla” z istniejących backupów na storage, bez dociągania całości z produkcji. mniej obciążenia dla serwerów, a porządek na S3

A co teraz, jeśli Backup chcemy przenieść do S3 ale przy odzyskiwaniu danych:

„Ktoś skasował VMkę” = odtwarzamy pojedyncze pliki, całe VM, bazy

„Ransomware zaszyfrował produkcję” = rollback do czystej wersji z backupu na S3

„Audyt/incydent” potrzebujemy danych sprzed 2 lat = wyciągamy z archiwum informując, że to potrwa dłużej (jednak, żeby zaoszczędzić koszty wsadziliśmy to do archiwum, prawda?)

Commvault + S3 to:

Wnioski końcowe jakimi chcę się podzielić, taki duet, to:

• Prosta konfiguracja od małej firmy z jednym Media Agentem po duże środowisko z HA i multi‑cloudem;
• Bezpieczeństwo szyfrowanie, wersjonowanie, klasę storage wybierasz pod RPO/RTO;
• Skalowalność jak rosną dane, po prostu rośnie bucket; nie trzeba kupować kolejnej macierzy;
• Koszty pod kontrolą dane w S3 Standard/lokalnym cache, a archiwum w tańszych klasach.