В настоящее время у меня есть ящик 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 . Если я не обратился ни к одному из ваших советов, пожалуйста, дайте мне знать, так как я действительно открыт для альтернатив. Я просто сейчас не вижу, как они дают мне какое-то преимущество.

3 ответа3

1

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

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

1

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


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

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


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

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


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

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

Далее вам нужно получить полный список наборов данных, которые вы хотите создать резервную копию, запустив zfs list -Hrt filesystem -o name ${ROOT} . Например, я хотел бы сделать резервную копию моего дерева 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 "${filesystem//\//___}"
ell___users___attie___archive

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

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

#!/bin/bash -eu

ROOT="${ZFS_ROOT}"
SNAPSHOT_NAME="rsync_$(date +%s)"
TMP_MNT="$(mktemp -d)"

RSYNC_TARGET="${REMOTE_USER}@${REMOTE_HOST}:${REMOTE_PATH}"

# take the sanpshots
zfs snapshot -r "${ROOT}"@"${SNAPSHOT_NAME}"

# push the changes... mounting each snapshot as we go
zfs list -Hrt filesystem -o name,rsync:sync "${ROOT}" \
    | while read filesystem sync; do
        [ "${sync}" != "false" ] && continue
        echo "Processing ${filesystem}..."

        # make a safe target for us to use... flattening out the ZFS hierarchy
        rsync_target="${RSYNC_TARGET}/${filesystem//\//___}"

        # mount, rsync umount
        mount -t zfs -o ro "${filesystem}"@"${SNAPSHOT_NAME}" "${TMP_MNT}"
        rsync -avP --exclude="/.zfs/" "${TMP_MNT}/" "${rsync_target}"
        umount "${TMP_MNT}"
    done

# destroy the snapshots
zfs destroy -r "${ROOT}"@"${SNAPSHOT_NAME}"

# double check it's not mounted, and get rid of it
umount "${TMP_MNT}" 2>/dev/null || true
rm -rf "${TMP_MNT}"
1

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

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

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

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


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


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

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

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

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

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

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .