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

14

У меня есть локальная система 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 recvна другом конце (например, в пуле zfs set compression=gzip-9). Хранение файлов моментальных снимков звучит очень неэффективно для меня.
Стефан Шазелас
1
@StephaneChazelas, потому что у меня нет файловой системы ZFS на другом конце. Моя удаленная система - это gentoo box с ext4 (я знаю, что могу установить zfsonlinux, но лучше нет)
Martin Grohmann

Ответы:

12

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).

Marco
источник
да это я знаю. Но что, если я удалю (потому что я хочу иметь историю только 30 дней) набор данных файла @ 2014-02-04? Тогда у меня есть только изменения, сделанные после 4 февраля, но не каждый файл.
Мартин Громанн
2
@MartinGrohmann Теперь я понимаю, что ты имеешь в виду. В этом-то и прелесть ZFS, вы можете без проблем удалять старые снимки на ZFS. На других файловых системах вы должны оставить старые. Может быть, вам лучше с чем-то вроде rsnapshotэтого. Или вы можете начать новый неинкрементный через один месяц, а затем удалить предыдущие инкрементные.
Марко
Спасибо за помощь; Я только что обнаружил двуличие. Это, вероятно, способ использовать шифрование.
Мартин Громанн
2
@MartinGrohmann Duplicity - хорошая программа, но она страдает от той же проблемы . Если вы делаете только приращения, ваше пространство продолжает расти. Вы не можете освободить место, не тратя пропускную способность и не создавая новую полную резервную копию. Либо перейдите на ZFS с обеих сторон, либо посмотрите на bareos , он может рассчитать новую полную резервную копию по инкрементам. Это позволяет вам удалять старые инкременты без повторной передачи всего.
Марко
Если проблема связана с пропускной способностью вашего источника, потенциальное решение (которое я сейчас реализую для своего домашнего ZFS NAS) состоит в том, чтобы всегда отправлять только инкрементные копии в ваше удаленное хранилище, но раз в месяц запускать удаленный VPS на FreeBSD (например, на цифровой океан), который может затем открыть последний полный снимок, zfs извлекает в него несколько инкрементов, а затем сохраняет результат как новый снимок. VPS должен быть достаточно длинным, чтобы создать новую базовую резервную копию. Digital Ocean имеет API, позволяющий легко создавать / уничтожать их VPS. А вашей локальной системе нужно только отправлять инкрементные резервные копии.
stuckj