Як виконувати додаткові / постійні резервні копії пулу zfs?


25

Як можна резервні файли zfs постійно / поступово створювати резервні копії за межами місця?

Я визнаю, що send/receiveнад ssh є одним із методів, який передбачає необхідність керувати знімками вручну.

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

Один із інструментів, який виглядає багатообіцяючим, це https://github.com/jimsalterjrs/sanoid, проте я переживаю, що широко відомий інструмент може принести більше шкоди, ніж користі, оскільки він може зіпсувати / видалити дані.

Як виконуються безперервні / додаткові резервні копії zfs?


2
Я відповім трохи пізніше, але у мене є рішення, яке виконує цей тип реплікації кожні 15 секунд від основного сервера ZFS до вторинного.
ewwhite

Відповіді:


33

ZFS - це неймовірна файлова система і вирішує багато моїх місцевих та спільних потреб у сховищі даних.

Хоча мені подобається ідея кластеризації ZFS, де це можливо, іноді це не практично, або мені потрібно певне географічне розділення вузлів зберігання.

Один із випадків використання у мене - це високоефективне реплікуване зберігання на серверах додатків Linux. Наприклад, я підтримую застарілий програмний продукт, який отримує вигоду з низькозатримних SSD-накопичувачів NVMe для своїх даних. У додатку є опція дзеркального відображення на рівні додатків, яка може реплікуватися на вторинний сервер, але часто неточна і становить 10-хвилинну RPO .

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

zfs-auto-знімок - https://github.com/zfsonlinux/zfs-auto-snapshot

Просто зручний інструмент для включення періодичних знімків рівня файлової системи ZFS. Я, як правило, працюю з наступним графіком щодо обсягів виробництва:

# /etc/cron.d/zfs-auto-snapshot

PATH="/usr/bin:/bin:/usr/sbin:/sbin"

*/5 * * * * root /sbin/zfs-auto-snapshot -q -g --label=frequent --keep=24 //
00 * * * * root /sbin/zfs-auto-snapshot -q -g --label=hourly --keep=24 //
59 23 * * * root /sbin/zfs-auto-snapshot -q -g --label=daily --keep=14 //
59 23 * * 0 root /sbin/zfs-auto-snapshot -q -g --label=weekly --keep=4 //
00 00 1 * * root /sbin/zfs-auto-snapshot -q -g --label=monthly --keep=4 //

Syncoid (Sanoid) - https://github.com/jimsalterjrs/sanoid

Ця програма може запускати спеціальне оснащення / реплікацію файлової системи ZFS до другої цілі. Я використовую лише синкоїдну частину продукту.

Якщо припустити server1 та server2 , просту команду запустіть з server2, щоб витягнути дані з server1 :

#!/bin/bash

/usr/local/bin/syncoid root@server1:vol1/data vol2/data

exit $?

Monit - https://mmonit.com/monit/

Моніт є надзвичайно гнучким планувальником роботи та керівником виконання. За замовчуванням він працює на 30-секундному інтервалі, але я модифікую конфігурацію, щоб використовувати 15-секундний базовий часовий цикл.

Приклад конфігурації, який виконує описаний вище сценарій реплікації кожні 15 секунд (1 цикл)

check program storagesync with path /usr/local/bin/run_storagesync.sh
        every 1 cycles
        if status != 0 then alert

Це легко автоматизувати та додавати через управління конфігурацією. Обертаючи виконання знімка / реплікації в Monit, ви отримуєте централізований статус, контроль роботи та оповіщення (електронна пошта, SNMP, користувацький сценарій).


Результатом є те, що у мене є сервери, які мають кілька місяців щомісячних знімків та багато точок відкату та утримання в межах: https://pastebin.com/zuNzgi0G - Плюс, безперервна 15-секундна атомна репліка:

# monit status

Program 'storagesync'
  status                            Status ok
  monitoring status                 Monitored
  last started                      Wed, 05 Apr 2017 05:37:59
  last exit value                   0
  data collected                    Wed, 05 Apr 2017 05:37:59
.
.
.
Program 'storagesync'
  status                            Status ok
  monitoring status                 Monitored
  last started                      Wed, 05 Apr 2017 05:38:59
  last exit value                   0
  data collected                    Wed, 05 Apr 2017 05:38:59

4
Дякую за публікацію, ваша відповідь феноменальна і саме те, що я шукав (від затримки до моніторингу процесу). Також читаю сайт github.com/ewwhite/zfs-ha/wiki, і я дуже вражений. Дякую ще раз :)
Грег

6

У вас є два різні способи:

  1. Традиційний, файлосистемно-агностичний спосіб, який використовується / застосовувався протягом останніх десятиліть, за допомогою інструментів типу rsyncабо Bacula. Там ви перевірили і (сподіваємось) стабільне, велике програмне забезпечення, яке можна налаштувати для величезних розгортань і його можна використовувати, навіть якщо ви переходите від ZFS
  2. Один із інструментів, на яких лежить ZFS send/recv. Це може бути власне рішення, скрипт або розширений скрипт із різних програм у Github та ін., Або більш багаті на функції інструменти, такі як Sanoid або ZnapZend (надсилати / recv з підтримкою та планами збереження mbuffer). У цьому випадку ви, швидше за все, не знайдете жодних великих «підприємницьких» (у негативному сенсі) рішень, але інструментів, які виконують лише одне завдання і можуть поєднуватися з іншими інструментами для задоволення вашої конкретної установки.

Взагалі я б довіряв лише інструменту, вихідний код якого доступний, і я би зберігав його максимально просто. Якщо send/recvви користуєтеся , вам не доведеться багато керувати, просто потрібно видалити знімок n-1 з локальної сторони, коли передача та встановлення знімка n на віддаленій стороні пройшли успішно.

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

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


Я не бачу, як би rsyncбазувалося рішення на основі постійної реплікації великої файлової системи корпоративного масштабу. Зміни можуть відбутися швидше, ніж rsyncможна було їх виявити.
Ендрю Генле

2
@AndrewHenle я також не виступав за це, я просто хотів його представити, оскільки в питанні не було вказано сфери / розміру даних або часових рамків. Тож у випадку нечастої дії це може бути можливість, якщо це має бути файлова система-агностик. Звичайно, ви втратите приємні дельти рівня блоку ...
user121391

@ user121391 Цілком погоджуюсь з вами щодо того, що Open Source є дорогою. Дякую за детальну відповідь.
Грег

@Dave так само, як я
набираю

1
настійно рекомендую znapzend
Трент Ллойд
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.