Какова эффективная стратегия автономного резервного копирования для зеркального пула ZFS?

Я использую пул ZFS, состоящий из двух зеркальных дисков. Для создания резервных копий вне сайта я купил еще два диска.

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

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

Как я могу хранить резервные копии вне сайта, которые не требуют полной операции восстановления? Должен ли я использовать другую файловую систему на моих дисках резервного копирования (например, экспортировать образ, а не включать его в пул ZFS)? Нужно ли создавать резервные копии в отдельном пуле и отправлять в него новые снимки по мере их создания?

После долгих экспериментов и экспериментов я нашел решение, хотя и с довольно большим компромиссом.

Прежде всего, варианты, которые я должен был исключить:

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

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

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

Мое решение похоже на использование attachи detach, однако оно использует onlineи offline. Преимущество заключается в том, что выполняется повторное преобразование дельты по сравнению с полным восстановлением, но недостатком является то, что пул всегда сообщает о DEGRADEDсостоянии (в пуле всегда два диска; вращающиеся offlineудаленные диски помечаются, когда они находятся в удаленном хранилище и в хранилище, а затем подключаются к сети). когда они на месте).

Итак, краткий обзор моей установки:

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

Когда приходит время вращать резервные копии:

• Я жду zfs scrubзавершения, чтобы разумно убедиться, что резервный диск не содержит ошибок

• Я zfs offlineдиск, который будет удален. После его оффлайн я hdparm -Y /dev/idбы раскрутил его. Через минуту я частично снимаю салазки диска (этого достаточно, чтобы обеспечить его потерю мощности), а затем оставляю его еще на минуту, прежде чем полностью вытащить диск, чтобы убедиться, что он перестал вращаться. Диск помещается в статическую сумку, а затем в защитный чехол и выходит за пределы площадки.

• Я ввожу другой внешний диск. Он устанавливается в поддон для горячей замены и раскручивается. Я использую zfs onlineдля восстановления диска в пул и запускаю частичное повторное копирование, чтобы сделать его параллельным.

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

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

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

Почему бы zfs не отправить ваши снимки на удаленный компьютер ZFS? Я использую простой скрипт bash для этого:

#!/usr/local/bin/bash
# ZFS Snapshot BASH script by Shawn Westerhoff
# Updated 1/14/2014

### DATE VARIABLES
# D = Today's date
# D1 = Yesterday's date
# D# = Today less # days date
Y=$(date -v-1d '+%m-%d-%Y')
D=$(date +%m-%d-%Y)
D1=$(date -v-1d '+%m-%d-%Y')
D10=$(date -v-10d '+%m-%d-%Y')
D20=$(date -v-20d '+%m-%d-%Y')

# Step 1: Make the snapshots

for i in $( zfs list -H -o name ); do
    if [ $i == tier1 ]
    then echo "$i found, skipping"
    else
    zfs snapshot $i@$D
    fi
done

# Step 2: Send the snapshots to backup ZFS sever

    for i in $( zfs list -H -o name ); do
        zfs send -i $i@$D1 $i@$D | ssh -c arcfour root@10.10.10.10 zfs recv $i
    done

# Step 3: Destroy snapshots that are 20 days old

for i in $( zfs list -H -o name ); do
        if [ $i == tier1 ]
        then echo "$i found, skipping"
        else
        zfs destroy $i@$D20
        fi
done

Я создал инструмент snapdump, который позволяет создавать инкрементные дампы ваших наборов данных zfs в чужую (не zfs) файловую систему. Snapdump также поддерживает восстановление добавочной цепочки снимков одной командой.