Знімок ZFS до файлу резервного копіювання з обертанням

У мене локальна система FreeNAS і хочу використовувати знімки ZFS для створення резервних копій.
FreeNAS має вбудовані завдання реплікації, які використовують

zfs send snapshot_name

щоб надіслати знімок у віддалену систему. Але для цього потрібна система з ZFS на іншому кінці.

Я хочу надіслати знімок в файл aa і надіслати цей стислий і зашифрований файл на віддалену машину.

Це можливо за допомогою

zfs send snapshot_name | gzip | openssl enc -aes-256-cbc -a -salt > file.gz.ssl

Щодня я роблю знімок пулу для зберігання даних і зберігаю кожен знімок протягом 30 днів.
З кожним зробленим знімком я передаю цей знімок у файл.
- у snapshot_file 1 є кожен файл у ньому (скажімо, 2 ГБ)
- у знімку_файла 2 є лише зміни в знімок_файлу 1 (скажімо, 5 МБ)
- знімок_файл 3 вміщує зміни у знімок_файлу 2; і так далі.

31-го дня знімок_file 1 видаляється (оскільки я хочу лише зміни за останні 30 днів)

Тому snapshot_file 2 повинен вмістити кожен файл (2 Гб знімка_файлу 1 + 5 МБ змін)

Але при такому підході щодня (з 31 дня) слід створити новий 2 ГБ файл і відправити у віддалену систему. Це занадто багато накладних витрат.

Який найкращий підхід використовувати знімки, перенесені на файл, як резервну стратегію з історією X днів?

PS: Я знаю, що там є багато програмного забезпечення для резервного копіювання (наприклад, rdiff-backup), яким я міг би скористатися. Але мені цікаво, як це можна було зробити.

Якщо ви зберігаєте знімки у файлах, на відміну від файлової системи (наприклад, з zfs receive), боюся, це неможливо.

ZFS на стороні, що приймає

Якщо ви використовуєте 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 Гб, якщо ви не запускаєте жодних служб і використовуєте лише їх zfs receive).