Jak obliczyć pojemność pamięci na niezmienne kopie zapasowe, czas przesyłania i koszty transferu z chmury dla kopii off-site

Wnioski budżetowe na kopię zapasową off-site najczęściej zawierają jeden z dwóch błędów: pamięć masową wymiaruje się jako „jedną kopię dysków” albo zapomina się o rachunku za transfer wychodzący z chmury (egress). Oba błędy wychodzą na jaw po kilku miesiącach — gdy retencja zapełni bucket albo przyjdzie pierwsza faktura.

W tym poradniku przedstawiamy wzory, których używamy do wymiarowania niezmiennej kopii off-site — pamięci masowej, czasu przesyłania, kosztów transferu wychodzącego i zasobów odtworzeniowych — wraz z przykładem obliczeń, który możesz dopasować do własnych danych.

Pięć parametrów, których potrzebujesz

1. Zajęte miejsce (D) — dane faktycznie zapisane na chronionych dyskach, a nie ich przydzielona pojemność. Dysk 4 TB zapełniony w 40% wnosi do obliczeń 1,6 TB.
2. Współczynnik redukcji danych (r) — efekt kompresji i deduplikacji uzyskiwany przez oprogramowanie do backupu; dla zróżnicowanych serwerów typowa wartość to 1,3–2×.
3. Dzienny wolumen zmian (Δ) — nowe i zmienione bloki w ciągu doby po redukcji. Zmierz go na podstawie rozmiarów kopii przyrostowych z obecnych backupów.
4. Polityka retencji — ile dziennych, tygodniowych i miesięcznych punktów przywracania przechowujesz.
5. Wzrost — oczekiwany przyrost danych w okresie obowiązywania umowy, zwykle 10–20% rocznie.

Wzór na pojemność przy retencji GFS

Przy kopiach w trybie incremental forever w pamięci obiektowej każdy punkt przywracania przechowuje tylko te bloki, które się zmieniły i nie są współdzielone z nowszymi punktami. Daje to proste oszacowanie:

Pojemność ≈ F + Nd × Δ + Nw × Δw + Nm × Δm + narzut

F   = D / r        pełna kopia
Nd  = punkty dzienne                       Δ  = dzienny wolumen zmian
Nw  = punkty tygodniowe poza dziennymi     Δw ≈ 2,5 × Δ
Nm  = punkty miesięczne poza tygodniowymi  Δm ≈ 6 × Δ
narzut ≈ 10% na Object Lock i metadane

Mnożniki tygodniowy i miesięczny odzwierciedlają to, że wiele dziennych zmian nadpisuje te same bloki; gdy zgromadzisz miesiąc historii, zastąp je zmierzonymi wartościami. Przykład obliczeń: 20 TB zajętego miejsca, redukcja 1,5× i 200 GB zmian dziennie.

Polityka retencji mniej więcej podwaja wymaganą pojemność. Ustalaj ją osobno dla każdego systemu: systemy kategorii I często potrzebują 12 punktów miesięcznych, a systemom testowym i pomocniczym wystarczy 14 dni.

Object Lock i narzut na niezmienność

Object Lock w trybie zgodności (compliance) przechowuje każdy obiekt do daty końca retencji, nawet gdy oprogramowanie do backupu już go nie potrzebuje. Dlatego narzędzia do tworzenia kopii zapasowych wydłużają blokady skokowo, o kilka dni naraz (na przykład Veeam zwykle dodaje do dziesięciu dni), a wygasłe punkty są usuwane dopiero po zakończeniu blokady. Zaplanuj w budżecie 10–15% ponad wynik obliczeń retencji i nigdy nie zakładaj 100% wykorzystania pamięci niezmiennej: pełnego bucketu nie da się wcześniej wyczyścić.

Pierwsza pełna kopia (seeding): przepustowość i czas trwania

Pierwsza pełna kopia to największy transfer. Zaplanuj łącze tak, aby jej przesłanie zakończyło się w ciągu dwóch tygodni, pamiętając, że przy długotrwałym transferze realnie dostępne jest tylko około 80% nominalnej przepustowości:

Dni = Dane (TB) × 8 000 000 / (Przepustowość (Mb/s) × 0,8 × 86 400)

Codzienne kopie przyrostowe są znacznie mniejsze: przesłanie 500 GB w ośmiogodzinnym oknie wymaga około 140 Mb/s, a po rozłożeniu na 24 godziny — poniżej 50 Mb/s.

Koszty transferu wychodzącego z chmury

Transfer danych z chmury publicznej rozlicza za każdy gigabajt dostawca chmury, a nie dostawca usługi backupu, dlatego we wniosku budżetowym powinien on stanowić osobną pozycję. Cennik katalogowy Azure dla transferu wychodzącego do internetu z Europy (routing przez sieć Microsoft):

W przykładzie obliczeń przesłanie pełnej kopii o rozmiarze 13,3 TB kosztuje około 1137 USD, a 6 TB miesięcznych zmian — około 513 USD miesięcznie, czyli 6160 USD rocznie. Rachunek można obniżyć na trzy sposoby: kompresją i deduplikacją przed transferem, tańszą opcją „preferencja routingu: internet” (0,08 i 0,065 USD za GB w pierwszych dwóch progach) oraz programami sponsorskimi lub programami kredytów chmurowych, które mogą już pokrywać subskrypcję.

Wymiarowanie zasobów odtworzeniowych

Testy odtwarzania wymagają mocy obliczeniowej i przestrzeni dyskowej w pobliżu pamięci z kopiami zapasowymi. Zwymiaruj pulę pod największy system, który musisz odtworzyć naraz, a nie pod przeciętny:

• Dysk: zajęte miejsce największego systemu plus 20% przestrzeni roboczej.
• Moc obliczeniowa: tyle vCPU i RAM, by uruchomić wszystkie jego serwery jednocześnie — na przykład dwie maszyny wirtualne po 8 vCPU i 32 GB.
• Czas: przetestowanie wszystkich systemów zajmuje zwykle od dwóch do czterech tygodni pracy puli w roku.

Lista kontrolna wymiarowania

• Mierz zajęte miejsce na każdym serwerze i rozmiar baz danych, a nie przydzieloną pojemność dysków.
• Pobierz z obecnych backupów rozmiary kopii przyrostowych z 30 dni, aby poznać rzeczywisty dzienny wolumen zmian.
• Uzgodnij retencję dla każdej kategorii systemów, zanim zapytasz o ceny.
• Dolicz 10–15% na niezmienność i 10–20% na wzrost.
• Zwymiaruj łącze dla pierwszej kopii na 14 dni lub krócej, a okno dzienne — na szczytowe tempo zmian.
• Ujmij transfer wychodzący z chmury we wniosku budżetowym jako osobną pozycję.

Nie chcesz liczyć samodzielnie? Prześlij nam dane wejściowe: zwymiarujemy suwerenną rezerwę kopii zapasowych off-site i przedstawimy architekturę z wyceną.