Żywotność i efektywność podwójnego tworzenia kopii zapasowych

Próbuję opracować strategię tworzenia kopii zapasowych dla niektórych klientów i skłaniam się ku duplikatom w przypadku zdalnej kopii zapasowej (już używam rdiff-backup do tworzenia kopii zapasowych wewnętrznych / lokalnych).

Czy rozsądne jest żądanie pełnej kopii zapasowej co jakiś czas? Ponieważ przyrost duplikatów jest przekazywany do przodu, każda przyrostowa kopia zapasowa opiera się na poprzednim przyrostie i wszystkie w dużej mierze polegają na ostatniej pełnej kopii zapasowej. Jeśli to się zepsuje, zdarzają się złe rzeczy. Powiązane pytanie: Czy Duplicity testuje spójność przyrostowych kopii zapasowych?

Zakładając, że chcę pełnej kopii zapasowej co jakiś czas, jak skutecznie duplikat tworzy tę pełną kopię zapasową? Czy może / czy sprawdza podpisy plików i kopiuje niezmienione dane z poprzednich pełnych kopii zapasowych / przyrostów? Zasadniczo tworzysz nowe „pełne” archiwum, przenosząc nowe / zmienione dane i scalając istniejące niezmienione dane?

Obecnie obawiam się, że potrzebne jest pełne tworzenie kopii zapasowych, ale konsekwentne korzystanie z pełnych kopii zapasowych przy dużej przepustowości sprawi, że dla niektórych klientów będzie to nieuzasadnione.

Myślę, że rozsądnie jest chcieć mieć pełną kopię zapasową od czasu do czasu: większość moich komputerów jest skonfigurowana do wykonywania jednej kopii zapasowej co kilka miesięcy. W tej liczbie nie ma nic magicznego: właściwa wartość będzie zależeć od tego, ile masz danych, jak szybko się zmienia, jak prawdopodobne jest, że chcesz przywrócić dane z niczego innego niż najnowsza migawka, ile kosztuje ruch i przestrzeń dyskowa i jaki jesteś paranoikiem. Inne osoby mogą potrzebować pełnej kopii zapasowej co tydzień.

O ile od czasu do czasu nie wykonasz pełnej kopii zapasowej, rozmiar archiwum i czas odzyskiwania będą nadal rosły.

Nie sądzę, że w duplikatach jest polecenie „sprawdź” http://pad.lv/660895 , ale byłoby miło, gdyby tak było. Rozsądne jest przeprowadzanie przywracania testowego co jakiś czas.

Powiązane pytanie dotyczy tego, czy należy zachować więcej niż jeden łańcuch kopii zapasowych. Znowu zależy to od kosztu. Jednym z powodów, dla których warto je zachować, jest możliwość przywrócenia z niego, jeśli bieżący łańcuch jest uszkodzony, z powodu awarii sprzętu, awarii systemu operacyjnego lub błędu duplikacji. Oczywiście, jeśli stary łańcuch jest bardzo stary, przywrócenie go może mieć ograniczoną wartość.

Wykonanie pełnej kopii zapasowej zawsze powoduje przesłanie pełnej kopii danych.

Jeśli problemem klienta jest ułamek użytej przepustowości, a nie opłaty drogowe, możesz chcieć uruchomić go np trickle.

To, o co prosisz, nazywa się syntetyczną pełną kopią zapasową , która odnosi się do procesu uzyskiwania pełnej kopii zapasowej poprzez połączenie przyrostowej kopii zapasowej z poprzednią pełną kopią zapasową po stronie docelowej (tj. Serwerem kopii zapasowych).

Nie jestem zaznajomiony z Duplicity, ale z ich witryny wydaje się, że nie wykonuje syntetycznych pełnych kopii zapasowych. Musisz przywrócić wszystkie wartości przyrostowe do wartości, na których są oparte. Jeśli to jest przypadek, prawdopodobnie będziesz chciał wymusić pełną kopię zapasową co tak często, ponieważ:

• Przejście miliona przyrostów prawdopodobnie spowoduje, że przywracanie będzie wolne
• Prawdopodobnie nie chcesz, aby przyrosty wracały do ​​początku czasów

Jednym ciekawym sposobem na uzyskanie syntetycznych pełnych jest użycie rsync z opcją --link-dest = DIR lub użycie rsnapshot . Przechowuje tylko różnice między każdą przyrostową kopią zapasową, ale każda z nich wydaje się być pełna. Usunięcie któregokolwiek z nich spowoduje automatyczne scalenie przyrostowe. Robi to poprzez magię twardych linków, więc różnice będą oparte na plikach (albo plik się zmienił i jest dołączony do pliku różnicowego, albo nie).