Migawka ZFS do pliku jako kopia zapasowa z rotacją

Mam lokalny system FreeNAS i chcę używać migawek ZFS do tworzenia kopii zapasowych.
FreeNAS ma wbudowane zadania replikacji, które wykorzystują

zfs send snapshot_name

aby wysłać migawkę do zdalnego systemu. Ale to wymaga systemu z ZFS na drugim końcu.

Chcę wysłać migawkę do pliku i wysłać ten skompresowany i zaszyfrowany plik do zdalnego komputera.

Jest to możliwe dzięki

zfs send snapshot_name | gzip | openssl enc -aes-256-cbc -a -salt > file.gz.ssl

Codziennie robię migawkę puli pamięci i przechowuję każdą migawkę przez 30 dni.
Z każdą wykonaną migawką potokuję tę migawkę do pliku.
- plik migawki 1 zawiera każdy plik (powiedzmy 2 GB)
- plik migawki 2 ma tylko zmiany w pliku migawki 1 (powiedzmy 5 MB)
- plik migawki 3 przechowuje zmiany w pliku migawki 2; i tak dalej.

31 dnia plik snapshot_file 1 jest usuwany (ponieważ chcę tylko zmiany z ostatnich 30 dni)

Dlatego plik snapshot_file 2 musi przechowywać każdy plik (2 GB pliku snapshot_file 1 + 5 MB)

Ale przy takim podejściu codziennie (od 31 dnia) należy utworzyć nowy plik 2 GB i wysłać go do zdalnego systemu. To za dużo narzutów.

Jakie byłoby najlepsze podejście do używania migawek przesyłanych do pliku jako strategii tworzenia kopii zapasowych z historią X dni?

PS: Wiem, że istnieje wiele programów do tworzenia kopii zapasowych (na przykład rdiff-backup), których mógłbym użyć. Ale jestem ciekawy, jak można to zrobić.

Jeśli przechowujesz migawki w plikach, w przeciwieństwie do systemu plików (np. Z zfs receive), obawiam się, że nie jest to możliwe.

ZFS po stronie odbierającej

Jeśli używasz ZFS po stronie wysyłającej i odbierającej, możesz uniknąć konieczności przesyłania całej migawki i przesyłaj tylko różnice między migawką w porównaniu do poprzedniej:

ssh myserver 'zfs send -i pool/dataset@2014-02-04 pool/dataset@2014-02-05' | \
  zfs receive

ZFS wie o migawkach i przechowuje wspólne bloki tylko raz. Zrozumienie migawek przez system plików umożliwia bezproblemowe usuwanie starych.

Inny system plików po stronie odbierającej

W twoim przypadku przechowujesz migawki w pojedynczych plikach, a twój system plików nie wie o migawkach. Jak już zauważyłeś, przerywa to rotację. Musisz albo przesłać całe migawki, co zmarnuje przepustowość i przestrzeń dyskową, ale umożliwi usunięcie pojedynczych migawek. Nie zależą od siebie. Możesz wykonywać przyrostowe migawki w następujący sposób:

ssh myserver 'zfs send -i pool/dataset@2014-02-04 pool/dataset@2014-02-05' \
  > incremental-2014-02-04:05

Aby przywrócić przyrostową migawkę, potrzebujesz również poprzednich migawek. Oznacza to, że nie można usunąć starych przyrostowych.

Możliwe rozwiązania

Możesz robić przyrostowe, jak pokazano w moim ostatnim przykładzie i robić nowe nie przyrostowe co miesiąc. Nowe przyrostowe zależą od tego przyrostowego i możesz swobodnie usuwać stare migawki.

Lub możesz spojrzeć na inne rozwiązania do tworzenia kopii zapasowych. Istnieje rsnapshot , który używa rsynci twardych linków. Wykonuje bardzo dobrą robotę podczas rotacji i jest bardzo wydajny w zakresie przepustowości, ponieważ wymaga pełnej kopii zapasowej tylko raz.

Potem są bosy . Robi przyrosty, które oszczędzają miejsce i pasmo. Ma bardzo miłą funkcję; może obliczyć pełną kopię zapasową z zestawu przyrostowego. Umożliwia to usunięcie starych przyrostów. Ale jest to dość złożony system i przeznaczony do większych konfiguracji.

Najlepszym rozwiązaniem jest jednak użycie ZFS po stronie odbierającej. Będzie wydajne pod względem przepustowości, pamięci masowej i znacznie szybsze niż inne rozwiązania. Jedyną naprawdę wadą, o której mogę myśleć, jest to, że powinieneś mieć co najmniej 8 GiB pamięci ECC na tym urządzeniu (możesz być w porządku z 4 GiB, jeśli nie uruchamiasz żadnych usług i tylko z niego korzystasz zfs receive).