Яка ефективна стратегія резервного резервного копіювання дзеркального басейну ZFS?

Я використовую пул ZFS, що складається з двох дзеркальних дисків. Щоб розпочати резервні копії, я придбав ще два диски.

Мій початковий план полягав у створенні резервної копії за межами сайтів, прикріпивши до дзеркала третій диск, чекаючи перезарядження ZFS, потім від'єднайте привід і перенесіть його за межі сайту. Це працює досить добре, але я здивований, що, як видається, виконується повний resilver кожного разу, коли диск приєднано (я прочитав і, можливо, неправильно зрозумів, що кожне вкладення призведе до поступового або дельтового перенапруги). Це призводить до того, що резервне копіювання займає більше часу, ніж допустимо.

Мої вимоги полягають у тому, щоб мати в офісі копію мого zpool та всі його знімки, які я можу обертати щодня. Це означає, що реструктуризація повинна зайняти не більше 24 годин - наразі це близько до цього, але наші плани щодо розширення нашого басейну висунуть його за рамки цих часових рамків.

Як я можу зберігати резервні копії за межами сайтів, які не потребують повної операції повторного перегляду? Чи варто використовувати на файлах резервного копіювання іншу файлову систему (наприклад, експортувати зображення, а не бути частиною пулу ZFS)? Чи потрібно створити резервні копії в окремому пулі та надсилати до нього нові знімки під час їх створення?

Після довгих роздумів та експериментів я знайшов рішення, хоча і з досить великою компромісією.

По-перше, варіанти, які мені довелося виключити:

• Наявність другого виїзного сервера ZFS з дзеркальним пулом не було можливим через вартість. Якби це був варіант, це, безумовно, був би найкращим підходом, використовуючи передачу / отримання ZFS для доставки знімків у віддалений пул.

• Маючи другий дзеркальний басейн ZFS на місці, з якого я міг зняти диски, щоб забрати додому. Це більш здійсненно, ніж перший варіант, але мені потрібно, щоб другий пул завжди мав два диски на місці (або використовувати дві копії даних на одному диску на сайті). В даний час у мене є чотири диски, і більше немає місця для п’ятої на сервері. Це був би справедливий підхід, але все ще не ідеальний.

• За допомогою приєднання та від'єднання ZFS поверніть резервний диск у дзеркальний пул та з нього. Це добре працює, але має виконувати повний resilver щоразу, коли диск додається. Це триває неприпустимо довго, і тому я не міг на це покладатися.

Моє рішення аналогічно використанню attachі detach, тим НЕ менш він використовує onlineі offline. Це має перевагу у виконанні дельта-резілліверінгу порівняно з повним перенапруженням, але недолік у тому, що пул завжди повідомляє про DEGRADEDстан (пул завжди має два диски; обертові офсетні диски позначаються, offlineколи вони знаходяться у віддаленому сховищі та resilver, а потім приходять в Інтернет коли вони на місці).

Отже, короткий підсумок та огляд моїх налаштувань:

У мене є один сервер ZFS і чотири однакові диски. ZFS налаштований на використання дзеркального пулу. Два з чотирьох дисків є постійними членами цього пулу. Інші два диски обертаються; один завжди знаходиться в сховищі за межами сайту, а інший є частиною пулу, щоб виконувати функції резервного копіювання.

Коли настає час обертати резервні копії:

• Я чекаю zfs scrubзавершення, щоб досить впевнитись, що резервний диск не містить помилок

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

• Я приношу в інший офсетний диск. Він встановлюється в лоток гарячої заміни і обертається. Я використовую zfs onlineдля відновлення диска в пул і розпочинаю часткове перенапруження, щоб зробити його одночасним.

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

Це працювало добре протягом останніх кількох тижнів, але я все-таки вважаю це хакерським підходом. Я буду відповідати, якщо у мене виникнуть якісь основні проблеми.

Оновлення: Після роботи з цим протягом декількох місяців я виявив, що в реальному використанні resilvering займає однаковий час як для від'єднання / приєднання, так і в режимі офлайн / онлайн. У моєму тестуванні я не думаю, що я працював скрабом - моя думка полягає в тому, що якщо диск не працює в режимі офлайн для скрабу, тоді він вимагає повного ресивера.

Чому б 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 також підтримує відновлення інкрементального ланцюжка знімків за допомогою однієї команди.