Ile miejsca na kopie zapasowe? Jak policzyć pojemność backupu, zanim zabraknie dysku
Pytanie „ile miejsca na kopie zapasowe?” zwykle pada dopiero wtedy, gdy jest za późno: zadanie backupu zgłasza błąd, bo dysk docelowy jest pełny, albo — gorzej — program po cichu usuwa najstarsze kopie, żeby zrobić miejsce na nowe. Firma myśli, że ma trzy miesiące historii, a ma dwa tygodnie. Dobra wiadomość jest taka, że pojemność backupu da się policzyć z wyprzedzeniem. Wystarczy kilka liczb, które administrator i tak powinien znać.
Ilość danych to dopiero punkt wyjścia
Najczęstszy błąd to założenie, że na backup potrzeba mniej więcej tyle miejsca, ile zajmują dane produkcyjne. To prawda tylko wtedy, gdy trzymasz jedną kopię i nadpisujesz ją co noc — a taka „strategia” nie chroni przed niczym, co zostanie zauważone później niż po jednym dniu: przypadkowym usunięciem pliku, uszkodzoną bazą czy zaszyfrowaniem danych przez ransomware.
Pojemność backupu zależy od czterech czynników:
- Rozmiaru danych źródłowych — ile faktycznie trzeba chronić (nie pojemność dysków, tylko zajęte miejsce).
- Retencji — jak długo i ile wersji kopii przechowujesz.
- Rodzaju kopii — pełne, przyrostowe czy różnicowe.
- Tempa zmian i wzrostu danych — ile danych zmienia się każdego dnia i jak szybko przybywa nowych.
Retencja: najważniejsza liczba w całym rachunku
Retencja to odpowiedź na pytanie: „do jakiego momentu w przeszłości chcę móc się cofnąć?”. Popularny schemat to kopie dzienne z ostatnich dwóch tygodni, tygodniowe z ostatnich dwóch miesięcy i miesięczne z ostatniego roku. Każdy taki poziom to kolejne punkty przywracania — i kolejne gigabajty.
Retencję warto ustalić na podstawie wymagań biznesowych i prawnych, a nie pojemności dysku, który akurat jest wolny. Jeśli audytor, dział księgowości albo umowa z klientem wymagają odtworzenia danych sprzed kilku miesięcy, backup musi to fizycznie umożliwiać. Więcej o tym, jak dobrać częstotliwość kopii, piszemy w artykule Jak często wykonywać kopię zapasową i jak ją testować w praktyce.
Kopie pełne i przyrostowe — jak je policzyć
Kopia pełna zajmuje tyle, ile chronione dane (przed kompresją). Kopia przyrostowa zawiera tylko to, co zmieniło się od poprzedniej kopii — jej rozmiar zależy od dziennego współczynnika zmian. Kopia różnicowa zawiera zmiany od ostatniej kopii pełnej, więc rośnie z każdym dniem cyklu.
Prosty model dla schematu „pełna raz w tygodniu + przyrostowe codziennie”:
pojemność ≈ (liczba przechowywanych kopii pełnych × rozmiar danych) + (liczba kopii przyrostowych × rozmiar danych × dzienny współczynnik zmian)
Przykład poglądowy: 500 GB danych, dzienna zmiana na poziomie kilku procent, retencja czterech tygodni. Cztery kopie pełne to już 2 TB, a do tego dochodzą kopie przyrostowe z każdego dnia. Wynik jest wielokrotnie większy niż same dane źródłowe — i to jeszcze przed uwzględnieniem wzrostu danych.
Własne liczby najłatwiej odczytać z istniejących zadań backupu: większość narzędzi raportuje rozmiar każdej kopii przyrostowej. Kilka tygodni obserwacji daje realny współczynnik zmian zamiast zgadywania.
Kompresja i deduplikacja: pomagają, ale nie licz na nie w ciemno
Nowoczesne narzędzia do backupu kompresują dane i usuwają powtarzające się bloki (deduplikacja). Na plikach tekstowych, logach czy maszynach wirtualnych z tym samym systemem efekt bywa duży. Na danych już skompresowanych lub zaszyfrowanych — archiwach, plikach multimedialnych, zaszyfrowanych bazach — niewielki albo żaden.
Dlatego bezpieczniej jest planować pojemność bez kompresji, a jej efekt traktować jako zapas. Jeśli dane zostaną zaszyfrowane przez ransomware, kolejna kopia przyrostowa może okazać się prawie tak duża jak pełna — bo zmienił się każdy blok. O tym, jak chronić kopie przed takim scenariuszem, piszemy w tekście Ransomware najpierw kasuje kopie zapasowe.
Zapas na wzrost danych i odtwarzanie
Do wyniku z poprzednich kroków dolicz dwie rzeczy:
- Wzrost danych w horyzoncie planowania. Jeśli dane przybywają w stałym tempie, pojemność policzona na dziś za rok będzie za mała. Planuj co najmniej na okres, na jaki kupujesz lub wynajmujesz przestrzeń.
- Miejsce robocze. Część narzędzi potrzebuje wolnej przestrzeni do scalania kopii, weryfikacji czy odtwarzania testowego. Dysk zapełniony w całości to dysk, na którym backup przestanie działać.
Dobrym nawykiem jest ustawienie alertu na zajętość przestrzeni backupowej, zanim dojdzie do 100%. A sama pojemność to nie wszystko — liczy się też to, czy z tych kopii da się odtworzyć dane. Jeśli tego nie sprawdzałeś, zajrzyj do artykułu Kiedy ostatnio odtwarzałeś dane z kopii zapasowej?.
Gdzie trzymać kopie: ten sam serwer to nie backup
Kopia na tym samym serwerze, a nawet na tej samej macierzy, nie chroni przed awarią sprzętu, błędem administratora ani atakiem. Kopie powinny trafiać na oddzielne urządzenie — a przynajmniej jedna z nich także do innej lokalizacji (szerzej: Disaster recovery i kopia zapasowa w drugiej lokalizacji).
Gdy już wiesz, ile miejsca potrzebujesz, masz dwie typowe drogi:
- Osobny serwer backupowy. W Sprint Data Center służy do tego linia BOX — serwery dedykowane przygotowane z myślą o roli serwera typu backup, dostępne w 8 modelach konfiguracji, z 10 TB transferu miesięcznie w cenie i ochroną anty-DDoS. Każdą konfigurację można przetestować przez 7 dni.
- Przestrzeń pod backup dokupowana elastycznie. W usługach dodatkowych znajdziesz powierzchnię pod backup rozliczaną w pakietach po 100 GB — wygodną, gdy potrzebujesz dołożyć miejsca bez zmiany całej konfiguracji. Automatyczne kopie dzienne lub tygodniowe można też zamówić jako usługę, którą wyceniamy i konfigurujemy indywidualnie.
Podsumowanie
Pojemność backupu to nie „dane plus trochę zapasu”, tylko wynik prostego rachunku: rozmiar danych × liczba przechowywanych wersji, z uwzględnieniem kopii przyrostowych, wzrostu danych i miejsca roboczego. Policz go raz, zapisz założenia i weryfikuj co kwartał na podstawie rzeczywistych raportów z zadań backupu. Wtedy dzień awarii nie będzie dniem, w którym odkryjesz, że najstarsza kopia ma tydzień.
Chcesz dobrać serwer backupowy albo przestrzeń na kopie do swojej retencji? Sprawdź linię BOX lub skontaktuj się z nami — pomożemy policzyć, ile miejsca naprawdę potrzebujesz.
FAQ – najczęściej zadawane pytania o pojemność kopii zapasowych
Ile razy więcej miejsca niż dane zajmuje backup?
To zależy od retencji i rodzaju kopii. Przy jednej nadpisywanej kopii to mniej więcej tyle, ile dane źródłowe, ale przy kilku tygodniach historii z kopiami pełnymi i przyrostowymi potrzebna przestrzeń jest zwykle kilkukrotnie większa niż same dane. Najdokładniej policzysz to na podstawie raportów z istniejących zadań backupu.
Czy kopie przyrostowe zawsze oszczędzają miejsce?
Zwykle tak, bo zawierają tylko zmiany od poprzedniej kopii. Wyjątkiem są sytuacje, w których zmienia się większość danych naraz — na przykład po zaszyfrowaniu plików przez ransomware lub po reorganizacji dużej bazy. Wtedy kopia przyrostowa może być prawie tak duża jak pełna, dlatego warto mieć zapas przestrzeni.
Czy mogę planować pojemność, licząc na deduplikację?
Lepiej traktować deduplikację i kompresję jako bonus, a nie podstawę planu. Dają duże oszczędności na powtarzalnych danych, ale niewielkie na plikach już skompresowanych lub zaszyfrowanych. Bezpieczniej policzyć pojemność bez nich i sprawdzić rzeczywisty efekt po kilku tygodniach pracy.
Czy kopie zapasowe mogą być na tym samym serwerze co dane?
Nie powinny. Kopia na tym samym serwerze nie chroni przed awarią sprzętu, błędem administratora ani atakiem, który obejmie cały system. Kopie powinny trafiać na oddzielne urządzenie, na przykład osobny serwer backupowy z linii BOX, a przynajmniej jedna z nich także do innej lokalizacji.
Jak często sprawdzać, czy przestrzeni na backup wystarczy?
Warto ustawić stały alert na zajętość przestrzeni backupowej i raz na kwartał porównać założenia z rzeczywistymi rozmiarami kopii. Przegląd jest konieczny także po każdej większej zmianie: migracji systemu, nowej aplikacji czy wydłużeniu wymaganej retencji.
Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu Sprint Data Center. Grafika ilustracyjna została wygenerowana przez AI.