Снимок ZFS в файл в качестве резервной копии с ротацией

У меня есть локальная система FreeNAS и я хочу использовать снимки ZFS для резервного копирования.
FreeNAS имеет встроенные задачи репликации, которые используют

zfs send snapshot_name

отправить снимок в удаленную систему. Но для этого нужна система с ZFS на другом конце.

Я хочу отправить снимок в файл и отправить этот сжатый и зашифрованный файл на удаленную машину.

Это возможно с

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

Каждый день я делаю снимок пула хранения и сохраняю каждый снимок в течение 30 дней.
С каждым сделанным снимком я передам этот снимок в файл.
- в файле snapshot_file 1 есть все файлы (скажем, 2 ГБ);
- в файле snapshot_file 2 есть только изменения в файле snapshot_file 1 (скажем, 5 МБ);
- файл snapshot_file 3 содержит изменения в файле snapshot_file 2; и так далее.

На 31-й день снимок_файла 1 удаляется (потому что я хочу изменения только за последние 30 дней)

Поэтому файл snapshot_file 2 должен содержать каждый файл (2 ГБ файла snapshot_file 1 + 5 МБ изменяется)

Но при таком подходе каждый день (с 31 дня) необходимо создавать новый файл объемом 2 ГБ и отправлять его в удаленную систему. Это слишком много накладных расходов.

Как лучше всего использовать моментальные снимки, переданные в файл в качестве стратегии резервного копирования с историей X дней?

PS: я знаю, что существует множество программ для резервного копирования (например, rdiff-backup), которые я мог бы использовать. Но мне любопытно, как это можно сделать.

zfs receiveБоюсь, если вы храните снимки в файлах, а не в файловой системе (например, с помощью ), это невозможно.

ЗФС на принимающей стороне

Если вы используете ZFS на отправляющей и принимающей сторонах, вы можете избежать передачи всего снимка и передавать только различия снимка по сравнению с предыдущим:

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

ZFS знает о снимках и сохраняет взаимные блоки только один раз. Если файловая система понимает снимки, вы можете без проблем удалить старые.

Другая файловая система на принимающей стороне

В вашем случае вы храните снимки в отдельных файлах, а ваша файловая система не знает о снимках. Как вы уже заметили, это нарушает вращение. Вы также должны передать целые снимки, что приведет к потере пропускной способности и места для хранения, но позволит вам удалить отдельные снимки. Они не зависят друг от друга. Вы можете делать инкрементальные снимки следующим образом:

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

Чтобы восстановить инкрементальный снимок, вам также нужны предыдущие снимки. Это означает, что вы не можете удалить старые инкременты.

Возможные решения

Вы можете делать приращения, как показано в моем последнем примере, и делать новые не приращения каждый месяц. Новые инкременты зависят от этого неинкрементного, и вы можете удалить старые снимки.

Или вы можете посмотреть другие решения для резервного копирования. Есть rsnapshot , который использует rsyncи жесткие ссылки. Он отлично справляется с ротацией и эффективно использует пропускную способность, так как полное резервное копирование требуется только один раз.

Тогда есть босоногие . Это делает приращения, которые экономят пропускную способность и пространство. У этого есть очень хорошая особенность; он может рассчитать полную резервную копию из набора приращений. Это позволяет вам удалить старые инкременты. Но это довольно сложная система и предназначена для больших установок.

Однако лучшее решение - использовать ZFS на принимающей стороне. Он будет эффективным по пропускной способности, хранилищу и намного быстрее, чем другие решения. Единственный недостаток, о котором я могу подумать, это то, что у вас должно быть минимум 8 GiB ECC памяти на этом блоке (вам может быть хорошо с 4 GiB, если вы не запускаете какие-либо сервисы и используете его только для этого zfs receive).