Dlaczego kopia zapasowa przyrostowa jest prawie tak duża jak pełna kopia zapasowa?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why Is an Incremental Backup Almost as Large as a Full Backup? - Zima Store Online

Kopia przyrostowa może stać się prawie tak duża jak pełna kopia, gdy źródło rzeczywiście przepisuje wiele bloków, silnik kopii zapasowej traci poprzednią bazę zmian, zakres chroniony się zmienia lub liczba, którą czytasz, to wzrost repozytorium, a nie aktualna wielkość przyrostu. Zdiagnozuj te możliwości osobno, zanim usuniesz punkty przywracania, zresetujesz zadanie lub rozpoczniesz nową pełną kopię zapasową.

Najpierw zidentyfikuj, która liczba wydaje się zbyt duża

„Przyrost jest pełnowymiarowy” może opisywać cztery różne pomiary. Nie są one wymienne i każdy wskazuje na inną przyczynę.

Pomiar	Co to oznacza	Co sugeruje duża wartość
Bajty źródłowe zeskanowane	Dane odczytane w celu wykrycia zmian	Silnik może potrzebować sprawdzić całe pliki, nawet jeśli przesyła tylko zmienione fragmenty
Przesłane bajty	Nowe dane wysłane do miejsca docelowego	Wiele bloków się zmieniło, baza odniesienia została utracona lub deduplikacja nie zadziałała
Rozmiar pliku przyrostowego	Nowe dane punktu przywracania zapisane podczas tego przebiegu	Zadanie uchwyciło rzeczywiście dużą różnicę lub zachowało się jak nowa baza odniesienia
Całkowity wzrost repozytorium	Netto dodane do magazynu po scaleniu, retencji, metadanych i operacjach syntetycznych	Projekt łańcucha kopii zapasowych lub harmonogram czyszczenia może być prawdziwą przyczyną

Zapisz wszystkie cztery liczby dla jednego przebiegu. Zadanie, które skanuje 8 TB, ale przesyła 12 GB, zachowuje się zupełnie inaczej niż to, które przesyła i zapisuje 7 TB.

Potwierdź, czy obciążenie rzeczywiście tak bardzo się zmieniło

Oprogramowanie do tworzenia kopii zapasowych na poziomie woluminu chroni zmienione bloki pamięci, a nie widoczny dla użytkownika rozmiar edytowanych dokumentów. Mała edycja może zmienić większy blok, a intensywnie działające usługi ciągle modyfikują logi, indeksy, bazy danych, pamięci podręczne i pliki systemu operacyjnego. Ostatnia dyskusja administratorów wyjaśnia, dlaczego jeden zmieniony bajt może sprawić, że zawierający go blok kopii zapasowej stanie się częścią następnego przyrostu.

Sprawdź, czy duży przebieg nastąpił po którymś z tych zdarzeń:

Konserwacja bazy danych, kompaktowanie, reindeksacja lub wzrost dziennika transakcji
Aktualizacje maszyn wirtualnych, aktywność swap, skanowanie antywirusowe lub defragmentacja gościa
Transkodowanie mediów, reindeksacja biblioteki zdjęć, regeneracja miniatur lub przepisywanie metadanych
Duże archiwa, zaszyfrowane kontenery, skrzynki pocztowe lub pliki obrazów dysków przepisywane na miejscu
Równoważenie systemu plików, rozszerzenie puli, przenoszenie bloków lub konsolidacja migawki

Porównaj okno tworzenia kopii zapasowej z logami aplikacji i wykresami zapisu na dysku. Jeśli zapisy źródłowe wzrosły w tym samym czasie, kopia zapasowa może raportować rzeczywistą różnicę, a nie błąd kopii zapasowej.

Sprawdź, czy śledzenie zmian utraciło swoją bazę odniesienia

Systemy śledzenia bloków porównują bieżący stan z znanym poprzednim identyfikatorem zmiany. Przywrócenie migawki, reset śledzenia, nieprawidłowa mapa zmian, migracja hosta, nieudana poprzednia sesja lub odtworzenie zadania kopii zapasowej mogą przerwać tę relację. Następne uruchomienie może wtedy odczytać lub chronić całe źródło, aby ustalić bezpieczną linię bazową. Praktyczny przewodnik po odzyskiwaniu CBT zauważa, że resetowanie śledzenia zmian może wymagać nowej aktywnej pełnej kopii przed wznowieniem normalnych przyrostów.

Szukaj w logach terminów takich jak reset CBT, nieprawidłowy identyfikator zmiany, zawinięty dziennik, brak linii bazowej, nowy łańcuchlub wymagane pełne skanowanieNie resetuj śledzenia wielokrotnie bez zachowania logów; powtarzające się resetowanie może ukryć pierwotny wyzwalacz i powodować powtarzające się pełnowymiarowe uruchomienia.

Zweryfikuj, czy zakres kopii zapasowej i tożsamość źródła nie uległy zmianie

Zadanie może nadal być oznaczone jako przyrostowe, chroniąc jednak inne źródło niż wcześniej. Nowy punkt montowania pod uwzględnioną ścieżką, zmiana rozmiaru systemu plików, zmieniony identyfikator urządzenia, inna nazwa hosta, nowa ścieżka udziału lub rozszerzone reguły uwzględniania mogą spowodować, że silnik zbuduje nowe struktury wewnętrzne. Społeczność rozwiązywania problemów pokazuje, że dodatkowe wolumeny i punkty montowania mogą zostać dołączone do zadania, które wydaje się niezmienione.

Eksportuj poprzednie i bieżące definicje zadań i porównaj:

Chronione korzenie, punkty montowania, udziały, zestawy danych i dyski wirtualne
Identyfikatory hosta, wolumenu i systemu plików
Wzorce do uwzględnienia i wykluczenia
Dostawca migawki i tryb spójności
Ustawienia szyfrowania, kompresji i deduplikacji

Jeśli źródło zostało celowo rozszerzone, można oczekiwać jednego pełnowymiarowego przyrostu. Jeśli każde kolejne uruchomienie pozostaje duże, kontynuuj diagnozę.

Określ, czy szczegółowość kopii zapasowej odpowiada plikom

Silniki dzielenia na fragmenty na poziomie pliku, bloku i zdefiniowanym przez zawartość reagują inaczej na edycje, zmiany nazw i przepisywanie. System deduplikacji bloków może zapisać tylko metadane podczas przenoszenia folderu; prostszy silnik na poziomie pliku może potraktować przeniesioną ścieżkę jako usunięty plik plus nowy plik. W jednym przykładzie opartym na blokach, zmiana nazwy katalogu zmienia metadane ścieżki bez ponownego przesyłania wszystkich niezmienionych bloków danych.

Duże pliki modyfikowalne wymagają szczególnej uwagi. Baza danych, obraz maszyny wirtualnej, zaszyfrowany sejf lub monolityczne archiwum mogą być w pełni odczytane, aby wykryć małe wewnętrzne zmiany, a ilość ostatecznie przechowywana zależy od granic fragmentów i deduplikacji. Dyskusja o dużych bazach danych opisuje, jak plik bazy danych o wielkości wielu gigabajtów może być odczytany w całości, nawet gdy przesyłane są tylko zmienione fragmenty.

Jeśli aplikacja zapewnia spójny eksport, kopię zapasową dziennika transakcji lub metodę kopii zapasowej świadomą aplikacji, porównaj ten proces z tworzeniem kopii zapasowej na żywo monolitycznego pliku.

Oddziel duży przyrost od aktywności pełnej syntetycznej i retencji.

Pełna syntetyczna jest tworzona wewnątrz repozytorium z wcześniejszej pełnej kopii oraz późniejszych przyrostowych. Może stworzyć obiekt odzyskiwania o pełnym rozmiarze bez ponownego czytania całego źródła. Przegląd typów kopii zapasowych wyjaśnia, że pełne kopie syntetyczne są budowane z istniejącego łańcucha pełnych i przyrostowych kopii.

Wzrost repozytorium może pozostać wysoki, gdy stare punkty przywracania są nadal zablokowane, przycinanie nie zostało wykonane, usunięte migawki nadal odwołują się do fragmentów lub scalanie tymczasowo potrzebuje przestrzeni roboczej. Sprawdź oś czasu zadania zamiast oceniać pojedynczą listę katalogów:

Zaobserwowany wzorzec.	Prawdopodobna interpretacja.	Następna kontrola.
Transfer sieciowy jest mały, zapis do repozytorium duży.	Pełna syntetyczna, scalanie lub przepakowanie.	Log zadań repozytorium.
Plik przyrostowy jest mały, całkowite użycie nadal rośnie.	Retencja, niezmienność, migawki lub opóźnione przycinanie.	Najstarszy zachowany punkt i harmonogram odzyskiwania.
Przesłane i zapisane bajty zbliżają się do pełnego rozmiaru.	Rzeczywiste zmiany, utracona baza odniesienia lub zmieniony zakres.	Aktywność źródła i logi śledzenia.
Tylko pierwsze uruchomienie po zmianie jest duże.	Nowa baza odniesienia lub przejście układu źródła.	Następne dwa uruchomienia przyrostowe.

Przeprowadź test jednej zmiennej przed odbudową łańcucha kopii zapasowej.

Zapisz aktualną konfigurację zadania, szczegółowe logi, listę punktów przywracania i pojemność repozytorium.
Wybierz ciche okno testowe i wstrzymaj znane aplikacje o dużym zapisie, jeśli jest to bezpieczne.
Utwórz jeden mały plik testowy, zmodyfikuj go raz i uruchom ten sam przyrostowy backup bez zmiany ustawień.
Zarejestruj zeskanowane, przesłane, zapisane, zduplikowane i zachowane bajty.
Uruchom drugi przyrostowy backup bez zmian w źródle.

Jeśli oba kontrolowane uruchomienia pozostają pełnowymiarowe, skup się na śledzeniu, identyfikacji źródła lub konfiguracji łańcucha zadań. Jeśli staną się małe, przywracaj normalne obciążenia pojedynczo, aż wskaźnik zmian wróci do normy. To oddziela zachowanie silnika kopii zapasowej od zmian w aplikacji.

Dopasuj naprawę do przyczyny

Potwierdzona przyczyna	Działanie korygujące	Oczekiwany wynik
Wysoka rzeczywista szybkość zapisu	Zmniejsz zakres plików tymczasowych, używaj eksportów świadomych aplikacji lub planuj po konserwacji	Rozmiar przyrostu odpowiada znaczącym zmianom danych
Utracona baza śledzenia	Śledzenie napraw raz, utworzenie wymaganej bazy, a następnie weryfikacja kolejnych przyrostów	Jedno duże uruchomienie, a następnie mniejsze różnice
Zakres rozszerzony	Potwierdź, że nowe dane są zamierzone lub podziel je na osobne zadanie	Przewidywalny wzrost powiązany z dodanym źródłem
Duże pliki modyfikowalne	Używaj zrzutów zgodnych z aplikacją lub metody kopii zapasowej świadomej fragmentów	Mniej niepotrzebnego przetwarzania i bezpieczniejsze przywracanie
Retencja lub operacje syntetyczne	Dostosuj planowanie pojemności, harmonogram przycinania lub politykę punktów przywracania	Wzrost repozytorium odpowiada zamierzonej historii

Przy określaniu rozmiaru miejsca docelowego pamiętaj, że historia wersji i retencja mogą sprawić, że repozytorium będzie większe niż aktywne źródło. Ten sam podział jest omówiony w przewodniku ZimaSpace dotyczącym planowania pojemności NAS dla wersji i historii kopii zapasowych.

Zatrzymaj i zgłoś problem, gdy każde uruchomienie tworzy nową bazę

Zgłoś problem przed usunięciem łańcucha, gdy logi pokazują powtarzające się unieważnienie bazy, nieoczekiwane zmiany identyfikatorów źródła, znikanie punktów przywracania, raporty o uszkodzeniu metadanych repozytorium lub gdy test bez zmian nadal zapisuje prawie cały materiał źródłowy. Zachowaj aktualne punkty przywracania, dopóki nie przetestujesz przynajmniej jednego reprezentatywnego przywrócenia. Ponowne utworzenie zadania może ukryć dowody i usunąć jedyną możliwą do odzyskania historię.

Najczęściej zadawane pytania

Czy przeniesienie lub zmiana nazwy dużego folderu może spowodować pełnowymiarowy przyrostowy backup?

To zależy od silnika kopii zapasowej. Narzędzia deduplikujące zawartość lub bloki mogą ponownie wykorzystać istniejące dane i przechowywać głównie metadane ścieżek, podczas gdy narzędzia na poziomie plików mogą traktować przeniesione pliki jako nowe obiekty. Przetestuj dokładny produkt na jednym reprezentatywnym folderze przed reorganizacją dużego zbioru danych.

Czy pełna kopia syntetyczna oznacza, że NAS ponownie przesłał cały źródłowy materiał?

Niekoniecznie. Pełna kopia syntetyczna jest zwykle składana z danych już znajdujących się w repozytorium. Porównaj liczniki odczytu źródła i transferu sieciowego z licznikami zapisu do repozytorium, aby zobaczyć, gdzie wykonano pracę.

Dlaczego mała edycja bazy danych może wygenerować duży przyrostowy backup?

Aplikacja może przepisywać wiele bloków pamięci masowej, kompaktować bazę danych, obracać logi lub zmieniać granice fragmentów nawet wtedy, gdy widoczna zmiana rekordu jest niewielka. Użyj kopii zapasowej zgodnej z aplikacją lub eksportu i porównaj jego różnicę z plikiem bazy danych na żywo.