резервное копирование пула ZFS с использованием rsync

1811
Octaviour

В настоящее время у меня есть ящик FreeNAS для хранения моих личных файлов. Я бы хотел иметь резервную копию вне сайта, но я не собираюсь тратить деньги на второй компьютер, способный правильно работать с ZFS. Поэтому я планировал использовать удаленные резервные копии с помощью rsync.

Я хотел бы, чтобы все файлы в резервной копии были согласованы, что, я думал, я мог бы сделать, сделав сначала рекурсивный снимок, а затем передав его с помощью rsync. Однако оказывается, что для каждого набора данных создается отдельный снимок.

Теперь мне интересно, есть ли какой-нибудь способ просмотреть рекурсивный снимок, включая все наборы данных, или есть какой-то другой рекомендуемый способ для rsyncцелого zpool. Я не думаю, что простая символическая ссылка на .zfsпапки в наборах данных будет работать, поскольку я хотел бы rsyncсохранить любые символические ссылки, которые присутствуют в самих наборах данных.

редактировать

Основываясь на полученных комментариях, я думаю, что некоторые детали моей желаемой конфигурации уже готовы. Я надеюсь, что у меня дома есть NAS, на котором я могу удобно размещать данные, зная, что вряд ли я когда-нибудь его потеряю. Для меня это означает наличие нескольких копий на месте, нескольких копий за пределами сайта, автономной копии на случай, если что-то пойдет не так, периодических снимков данных в случае случайного удаления и средства предотвращения ошибок данных (например, гниение битов). Чем меньше вероятность того, что событие произойдет, тем более расслабленным будет отсутствие нескольких копий данных после катастрофы, и тем меньше я буду заботиться о снимках. Кроме того, я забочусь о старых данных больше, чем о новых данных, поскольку у меня обычно есть копия на другом устройстве. Наконец, я должен отметить, что большинство файлов не обновляются слишком часто. Большинство переводов будут новыми файлами.

Моей предыдущей установкой был набор из двух Raspberry Pi с подключенными внешними жесткими дисками по 4 ТБ. Я потерял доверие к этой стратегии, но аппаратное обеспечение было легко доступно. После некоторых исследований выяснилось, что единственный способ предотвратить проникновение ошибок со временем - это использовать файловую систему контрольной суммы, такую ​​как ZFS, в сочетании с компонентами серверного уровня, такими как ECC RAM и UPS. Для своей локальной копии я пошел по этому пути. Я использую 2x4TB диски в зеркале и делаю регулярные снимки здесь.

Эта машина должна покрывать все случаи, за исключением резервного копирования вне сайта и в автономном режиме. Поскольку мне скорее всего не понадобятся эти резервные копии, я не хочу вкладывать в них слишком много. Поэтому я решил, что могу пойти с Raspberry Pi и внешними дисками, которые у меня уже лежали. Я мог бы сделать так, чтобы один из дисков всегда был в автономном режиме, а другой получал резервные копии. Замена дисков через равные промежутки времени позволила бы мне иметь автономную резервную копию моих старых данных.

Прямым маршрутом будет использование zfs sendи receiveдвух пулов, по одному на каждый диск. Raspberry Pi в сочетании с USB-подключением к жесткому диску, однако, не обеспечит zfs(или, если на то пошло, файловую систему) очень надежную среду для работы. Поэтому я ожидаю, что ошибки в этой установке будут происходить довольно регулярно. Поскольку я буду использовать только один диск, у zfsменя не будет надежных средств для восстановления после сбоя.

Вот почему я хотел бы пойти с ext3или в ext4сочетании с rsync. Конечно, некоторые плохие биты могут быть записаны на диск. В случае метаданных существуют инструменты для решения большинства из этих проблем. В случае блоков данных это приведет к потере одного файла. Кроме того, файл может быть восстановлен с использованием, rsync -cпоскольку он найдет неверную контрольную сумму и снова передаст файл из заведомо исправной копии на локальный компьютер. Учитывая неидеальное аппаратное обеспечение, это кажется наилучшим возможным решением.

Это мой аргумент в пользу использования rsync, который привел меня к первоначальному вопросу о том, как сделать rsyncрекурсив zfs snapshot. Если я не обратился ни к одному из ваших советов, пожалуйста, дайте мне знать, так как я действительно открыт для альтернатив. Я просто сейчас не вижу, как они дают мне какое-то преимущество.

0

3 ответа на вопрос

1
Attie

Я бы настоятельно рекомендовал использовать zfs sendи zfs receiveболее rsync- это будет значительно быстрее и принесет другие важные преимущества (например: отсутствие пропущенных изменений, шифрование без необходимости использования ключей).

Существуют службы хранения, которые предоставят вам возможность передавать в них наборы данных (аналогично использованию службы, которая поддерживает rsync).

Есть даже хороший инструмент syncoid(часть проекта sanoid ), который я очень рекомендую. Он управляет моментальными снимками и позволяет выполнять операции push или pull.

В этом докладе обсуждаются различия между zfs send/recvи rsync.

В качестве продолжения я только что переехал из Обнама (который сейчас на пенсии) и остановился на ZFS со снимками. Я также только что прошел процесс исследования сторонних сервисов хранения и (исходя из объема хранилища, который мне требуется) пришел к выводу, что создание и размещение машины в удаленном месте будет дешевле, чем использование выделенной службы хранения до ~ 1 год ... хотя, конечно, примите свое собственное решение.

Чтобы ответить на некоторые из ваших утверждений:

Я не хочу тратить деньги на второй компьютер, способный правильно работать с ZFS.

Стоит отметить, что ZFS не нужно использовать ОЗУ ECC, и что вы можете легко запускать ZFS на одном диске - это резервное копирование вне сайта, так что это вполне может быть приемлемо для вас.

Для меня создание собственной машины было примерно такой же ценой, как облачное хранилище.

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

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

Для меня создание собственной машины было примерно такой же ценой, как облачное хранилище. Так как мне нравится возиться, и поскольку я смогу получить дополнительную функциональность, создав собственную машину (Plex, VPN, git-репозитории и т. Д.), Я решил пойти по этому пути. Я понимаю, что в идеале я бы сделал резервную копию на аналогичном компьютере, но это было бы слишком дорого (так же, как резервное копирование в облако). В случае, если мое место сгорит или что-то еще, я хотел бы иметь две резервные копии за пределами сайта. Нет необходимости в управлении версиями или чем-то еще, я просто хочу, чтобы мои файлы были в этом крайнем случае. Вот почему я действительно хотел бы использовать rsync или подобное для этого. Octaviour 6 лет назад 0
Я не уверен, что следую вашей логике. Я обновил свой ответ, чтобы уточнить некоторые моменты. Attie 6 лет назад 0
Мне не удобно работать с ZFS на неподходящем оборудовании. Одна ошибка памяти в плохом месте может повредить слишком много данных, потенциально без моего ведома. Кроме того, в настоящее время у меня есть Raspberry Pi и внешний жесткий диск, доступный из другого проекта. Таким образом, движение по дороге rsync обходится без затрат. Кроме того, форматирование в `ext4` облегчает считывание диска на случай, если что-то пойдет не так. Octaviour 6 лет назад 0
"_improper hardware _"? ... вы читали ссылки? Я признаю, что RPi не будет отличным ZFS-хостом ... Attie 6 лет назад 0
Честно говоря, я прочитал статью пару месяцев назад. Я просто перечитал это. Мне кажется, что ни одна файловая система не может работать надежно без ECC RAM. Можно всегда немного перевернуться перед записью на диск. `zfs` не хуже, но и не лучше в этом отношении. Проблема с `zfs` в этом случае заключается в том, что однобитовая ошибка может быть гораздо труднее исправить. Пожалуйста, смотрите мой отредактированный оригинальный пост, чтобы узнать, как я планировал обеспечить некоторую устойчивость, используя `ext`. Octaviour 6 лет назад 0
Я говорил это раньше, и я скажу это снова ... "Я постоянно удивляюсь, что ** все ** работает вообще" Attie 6 лет назад 0
1
Dan

Я согласен с другими ответами, что в целом вам лучше использовать zfs send.

Однако, если вы решили использовать rsyncвместо этого, и все, что вам нужно, это согласованный снимок всего пула, вы можете сделать это с помощью рекурсии zfs snapshot. Хотя снимки появляются отдельно в выходных данных zfs listдля каждого затронутого набора данных / тома, они делаются в согласованный момент времени (т.е. они являются « атомарными » - все они одинаковы txgв жаргоне ZFS-internals).

Вы также думаете, что `zfs send` - хороший вариант на очень дешевом оборудовании? Octaviour 6 лет назад 0
Я понимаю, что рекурсивный снимок будет последовательным. Тем не менее, я не вижу, как я могу передать этот снимок на удаленную машину с помощью `rsync`. Изначально я планировал сделать цикл `for` в` bash`, повторяя все наборы данных. Поскольку наборы данных являются вложенными, последующие запуски `rsync` удаляют данные, записанные ранее. Octaviour 6 лет назад 0
rsync будет использовать больше ресурсов, чем отправляет zfs, чтобы определить, какие блоки изменились (больше операций ввода-вывода, больше памяти, больше процессора), поэтому я не понимаю, как использование дешевого оборудования в этом случае будет иметь значение. ZFS обычно потребляет много оперативной памяти из-за кеша, но вам не стоит беспокоиться об этом для системы, которая только получает резервные копии. Dan 6 лет назад 1
Ресурсы на удаленном хосте не являются проблемой, поскольку его единственной целью будут резервные копии. Локальный хост, вероятно, будет выполнять немного больше работы, но поставляется с возможностью исправления удаленной копии в сочетании с `rsync -c`, как описано выше. Для меня это стоит дополнительных вычислений. Пожалуйста, смотрите отредактированный, оригинальный пост для более подробной информации. Octaviour 6 лет назад 0
1
Attie

Похоже, вы настроены на использование rsyncRaspberryPi, и вот еще один ответ с небольшим кусочком мозгов, который, надеюсь, поможет вам найти решение.

Теперь мне интересно, есть ли способ просмотреть рекурсивный снимок, включая все наборы данных, или есть какой-то другой рекомендуемый способ rsync для всего zpool.

Не то, чтобы я знал ... Я ожидаю, что рекомендации будут соответствовать моему другому ответу.

Если вы довольствовались простым запуском rsyncв смонтированном пуле ZFS, вы можете либо исключить использование .zfsкаталогов (если они вам видны) rsync --exclude='/.zfs/', либо установить snapdir=hiddenсвойство.

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

Вы захотите управлять моментальными снимками и захотите создать новый моментальный снимок для « сейчас », создать его резервную копию и, возможно, впоследствии удалить. Выбор этого подхода (а не просто использование « живых » смонтированных файловых систем) даст вам непротиворечивую резервную копию на определенный момент времени. Это также гарантирует, что вы не создадите резервную копию каких-либо странных иерархий или пропустите какие-либо файловые системы, которые могут быть смонтированы в другом месте.

$ SNAPSHOT_NAME="rsync_$(date +%s)" $ zfs snapshot -r $@$ $ # do the backup... $ zfs destroy -r $@$

Затем вам нужно получить полный список наборов данных, которые вы хотите создать резервную копию, запустив zfs list -Hrt filesystem -o name $. Например, я хотел бы сделать резервную копию моего usersдерева, ниже приведен пример:

$ zfs list -Hrt filesystem -o name ell/users ell/users ell/users/attie ell/users/attie/archive ell/users/attie/dropbox ell/users/attie/email ell/users/attie/filing_cabinet ell/users/attie/home ell/users/attie/photos ell/users/attie/junk ell/users/nobody ell/users/nobody/downloads ell/users/nobody/home ell/users/nobody/photos ell/users/nobody/scans

Это дает вам рекурсивный список файловых систем, которые вас интересуют ...

Однако вы можете пропустить определенные наборы данных, и я бы порекомендовал использовать свойство для достижения этого - например rsync:sync=true, помешал бы синхронизировать этот набор данных. Это тот же подход, который я недавно добавилsyncoid .

Поля ниже разделены символом табуляции.

$ zfs list -Hrt filesystem -o name,rsync:sync ell/users ell/users - ell/users/attie - ell/users/attie/archive - ell/users/attie/dropbox - ell/users/attie/email - ell/users/attie/filing_cabinet - ell/users/attie/home - ell/users/attie/photos - ell/users/attie/junk false ell/users/nobody - ell/users/nobody/downloads - ell/users/nobody/home - ell/users/nobody/photos - ell/users/nobody/scans -

Вы также должны понимать, что (как указано выше), поскольку наборы данных ZFS могут быть смонтированы где угодно, не очень хорошо думать о них так, как они представлены в VFS ... Это отдельные объекты, и вы должны обращаться с ними как например.

Чтобы достичь этого, мы сгладим имена файловых систем, заменив любую косую черту /тремя символами подчеркивания ___(или другим разделителем, который обычно не появляется в имени файловой системы).

$ filesystem="ell/users/attie/archive" $ echo "$" ell___users___attie___archive

Все это может собраться в простой скрипт bash ... что-то вроде этого:

ПРИМЕЧАНИЕ: я только кратко проверил это ... и должно быть больше обработки ошибок.

#!/bin/bash -eu  ROOT="$" SNAPSHOT_NAME="rsync_$(date +%s)" TMP_MNT="$(mktemp -d)"  RSYNC_TARGET="$@$:$"  # take the sanpshots zfs snapshot -r "$"@"$"  # push the changes... mounting each snapshot as we go zfs list -Hrt filesystem -o name,rsync:sync "$" \ | while read filesystem sync; do [ "$" != "false" ] && continue echo "Processing $..."  # make a safe target for us to use... flattening out the ZFS hierarchy rsync_target="$/$"  # mount, rsync umount mount -t zfs -o ro "$"@"$" "$" rsync -avP --exclude="/.zfs/" "$/" "$" umount "$" done  # destroy the snapshots zfs destroy -r "$"@"$"  # double check it's not mounted, and get rid of it umount "$" 2>/dev/null || true rm -rf "$"
Спасибо вам за то, что вы даже написали несколько сценариев, когда вы изначально даже не согласились с моей точкой зрения. Итерации по наборам данных, кажется, лучшее решение. Есть ли конкретная причина для монтирования снимка, а не просто для копирования каталога `.zfs / snapshot`? Octaviour 6 лет назад 0
Нет проблем, я надеюсь, что это полезно :-) Attie 6 лет назад 0
Основной причиной явного монтирования его куда-то может быть вопрос «где он монтируется?» (Как упомянуто выше) ... без проверки свойства `mountpoint` файловой системы и решения всех проблем, которые влекут за собой, вы не можете быть уверены, где файловая система появляется в VFS. Attie 6 лет назад 0

Похожие вопросы