У цій статті розглядатимуться програмні засоби для резервного копіювання, які шляхом розбиття потоку даних на окремі компоненти (chunks) формують репозиторій.
Компоненти репозиторію можуть додатково стискатися та шифруватися, а найголовніше – при повторних процесах резервного копіювання – перевикористовувати повторно.
Резервна копія в подібному репозиторії - іменований ланцюжок пов'язаних один з одним компонентів, наприклад, на основі різних hash-функцій.
Є кілька подібних рішень, я зупинюся на 3: zbackup, borgbackup та restic.
Очікувані результати
Оскільки всі претенденти так чи інакше вимагають створення репозиторію, одним із найважливіших факторів буде оцінка розміру репозиторію. В ідеальному випадку його розмір повинен бути не більше 13 гб згідно з прийнятою методикою, а то й меншим — за умови гарної оптимізації.
Також вкрай бажано мати можливість створювати резервні копії файлів безпосередньо без застосування архіваторів типу tar, а також роботу з ssh/sftp без додаткових засобів на кшталт rsync і sshfs.
Поведінка під час створення резервних копій:
- Розмір репозиторію дорівнюватиме розміру змін, або менше.
- Очікується велике навантаження на процесор при використанні стиснення та/або шифрування, а також можливе досить велике навантаження на мережу та дискову підсистему, якщо процес архівації та/або шифрування буде працювати на сервері зберігання резервних копій.
- Якщо пошкодити репозиторій, то ймовірна відкладена помилка як при створенні нових резервних копій, так і при спробі відновлення. Потрібно планувати додаткові заходи щодо забезпечення цілісності репозиторію або використовувати вбудовані засоби перевірки його цілісності.
Як еталонне значення прийнято роботу з tar, як це було показано в одній з минулих статей.
Тестування zbackup
Загальний механізм роботи zbackup полягає в тому, що програма знаходить у потоці даних, що подається на вході області, що містять однакові дані, потім опціонально їх стискає, шифрує, зберігаючи кожну область лише 1 раз.
Для дедуплікації використовується 64-бітова кільцева hash-функція з ковзним вікном для побайтної перевірки на збіг з вже існуючими блоками даних (подібно до того, як це реалізовано в rsync).
Для стиснення застосовується lzma та lzo у багатопотоковому виконанні, а для шифрування – aes. В останніх версіях є можливість у майбутньому видаляти старі дані з репозиторію.
Програма написана на C++ із мінімальними залежностями. Автор, очевидно, надихався unix-way, тому програма приймає дані на stdin при створенні резервних копій, видаючи аналогічний потік даних у stdout при відновленні. Таким чином, zbackup можна використовувати як дуже непогану «цеглинку» при написанні власних рішень резервного копіювання. Наприклад, автор статті ця програма є основним засобом резервного копіювання для домашніх машин приблизно з 2014 року.
Як поток даних буде застосовуватися звичайний tar, якщо не сказано інакше.
Подивимося, які будуть результати:
Перевірка роботи виконувалася у 2 варіантах:
- створюється репозиторій та запускається zbackup на сервері з вихідними даними, потім вміст репозиторію передається на сервер зберігання резервних копій.
- створюється репозиторій на сервері зберігання резервних копій, запускається zbackup через ssh на сервері зберігання резервних копій, йому через pipe видаються дані.
Результати першого варіанта були такі: 43m11s – при використанні нешифрованого репозиторію та компресора lzma, 19m13s – при заміні компресора на lzo.
Навантаження на сервері з вихідними даними було наступним (показаний приклад з lzma, з lzo була приблизно така ж картинка, але частка rsync була приблизно чверть від часу):
Ясно видно, що подібний процес резервного копіювання годиться лише за відносно рідкісних та невеликих змін. Також дуже бажано обмежувати роботу zbackup в 1 потік, інакше буде дуже високе завантаження процесором, т.к. програма дуже добре вміє працювати у кілька потоків. Навантаження на диск було невелике, що загалом при сучасній дисковій підсистемі на основі ssd буде непомітно. Також чітко видно запуск процесу синхронізації даних репозиторію на віддалений сервер, швидкість роботи можна порівняти зі звичайним rsync і впирається у продуктивність дискової підсистеми сервера зберігання резервних копій. Мінусом підходу є зберігання локального репозиторію і, як наслідок, дублювання даних.
Більш цікавим і застосовним практично є другий варіант із запуском zbackup відразу на сервері зберігання резервних копій.
Для початку буде перевірено роботу без використання шифрування з компресором lzma:
Час роботи кожного тестового запуску:
Запуск 1
Запуск 2
Запуск 3
39м45с
40м20с
40м3с
7м36с
8м3с
7м48с
15м35с
15м48с
15м38с
Якщо активувати шифрування із застосуванням aes, результати досить близькі:
Час роботи на тих же даних із шифруванням:
Запуск 1
Запуск 2
Запуск 3
43м40с
44м12с
44м3с
8м3с
8м15с
8м12с
15м0с
15м40с
15м25с
Якщо шифрування поєднати зі стисненням на lzo, виходить так:
Час роботи:
Запуск 1
Запуск 2
Запуск 3
18м2с
18м15с
18м12с
5м13с
5м24с
5м20с
8м48с
9м3с
8м51с
Розмір результуючого репозиторію був відносно однаковий і становив 13гб. Це означає, що дедуплікація працює коректно. Також на вже стислих даних застосування lzo дає відчутний ефект, за загальним часом роботи zbackup впритул наближається до duplicity/duplicati, проте відстаючи від заснованих на librsync у 2-5 разів.
Переваги є очевидними — економія дискового простору на сервері зберігання резервних копій. Що стосується інструментів перевірки репозиторію — автором zbackup вони не передбачені, рекомендується застосовувати стійкий до відмов дисковий масив або хмарний провайдер.
Загалом дуже непогане враження, незважаючи на те, що проект приблизно 3 роки стоїть на місці (останній feature request був близько року тому, але без відповіді).
Тестування borgbackup
Borgbackup є attic форком, ще однією, схожою з zbackup системи. Написаний на python, має схожий на zbackup список можливостей, але додатково вміє:
- Монтувати резервні копії через fuse
- Перевіряти вміст репозиторію
- Працювати в режимі клієнт-сервер
- Використовувати різні компресори для даних, а також евристичне визначення типу файлу під час його компресії.
- 2 варіанти шифрування, aes та blake
- Вбудований засіб для
перевірки продуктивності
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Результати вийшли такі:
CZ-BIG 96.51 MB/s (10 100.00 MB all-zero files: 10.36s)
RZ-BIG 57.22 MB/s (10 100.00 MB all-zero files: 17.48s)
UZ-BIG 253.63 MB/s (10 100.00 MB all-zero files: 3.94s)
DZ-BIG 351.06 MB/s (10 100.00 MB all-zero files: 2.85s)
CR-BIG 34.30 MB/s (10 100.00 MB random files: 29.15s)
RR-BIG 60.69 МБ/с (10 100.00 MB random files: 16.48s)
UR-BIG 311.06 MB/s (10 100.00 MB random files: 3.21s)
DR-BIG 72.63 MB/s (10 100.00 MB random files: 13.77s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB all-zero files: 9.21s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB all-zero files: 13.13s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB all-zero files: 3.02s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB all-zero files: 2.58s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB random files: 26.45s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB random files: 14.51s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB random files: 2.88s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB random files: 20.49s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB all-zero files: 8.53s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB all-zero files: 3.07s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB all-zero files: 5.16s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB all-zero files: 2.97s)
CR-SMALL 6.85 MB/s (10000 10.00 kB random files: 14.60s)
RR-SMALL 31.27 MB/s (10000 10.00 kB random files: 3.20s)
UR-SMALL 12.28 MB/s (10000 10.00 kB random files: 8.14s)
DR-SMALL 18.78 MB/s (10000 10.00 kB random files: 5.32s)
При тестуванні використовуватиметься евристика при компресії з визначенням типу файлу (compression auto), а результати будуть такі:
Для початку перевіримо роботу без шифрування:
Час роботи:
Запуск 1
Запуск 2
Запуск 3
4м6с
4м10с
4м5с
56s
58s
54s
1м26с
1м34с
1м30с
Якщо увімкнути авторизацію репозиторію (режим authenticated), результати вийдуть близькими:
Час роботи:
Запуск 1
Запуск 2
Запуск 3
4м11с
4м20с
4м12с
1м0с
1м3с
1м2с
1м30с
1м34с
1м31с
При активації шифрування результати не сильно погіршилися:
Запуск 1
Запуск 2
Запуск 3
4м55с
5м2с
4м58с
1м0с
1м2с
1м0с
1м49с
1м50с
1м50с
А якщо поміняти aes на blake, ситуація зовсім покращає:
Час роботи:
Запуск 1
Запуск 2
Запуск 3
4м33с
4м43с
4м40с
59s
1м0с
1м0с
1м38с
1м43с
1м40с
Як і у випадку з zbackup, розмір репозиторію становив 13гб і навіть трохи менше, що загалом очікувано. Дуже порадував час роботи, він можна порівняти з рішеннями на основі librsync, забезпечуючи набагато ширші можливості. Також порадувала можливість завдання різних параметрів через змінні оточення, що дає дуже серйозну перевагу при використанні borgbackup в автоматичному режимі. Також порадувало навантаження при резервному копіюванні: судячи із завантаження процесора - borgbackup працює в 1 потік.
Особливих мінусів під час використання не виявилося.
Тестування restic
Незважаючи на те, що restic досить нове рішення (перші 2 кандидати були відомі ще з 2013 року і старше), він має досить непогані характеристики. Написаний Go.
Якщо порівнювати із zbackup, додатково дає:
- Перевірку цілісності репозиторію (включаючи перевірку частинами).
- Величезний список протоколів і провайдерів для зберігання резервних копій, що підтримуються, а також підтримку rclone — rsync для «хмарних» рішень.
- Порівняння 2 резервних копій між собою.
- Монтування репозиторію через fuse.
Загалом список можливостей досить близький до borgbackup, подекуди більше, подекуди менше. З особливостей - відсутність можливості відключення шифрування, а отже, резервні копії будуть завжди зашифрованими. Давайте подивимося практично, що можна вичавити з цього ПО:
Результати вийшли такі:
Час роботи:
Запуск 1
Запуск 2
Запуск 3
5м25с
5м50с
5м38с
35s
38s
36s
1м54с
2м2с
1м58с
Результати роботи також можна порівняти з рішеннями на основі rsync і, в цілому, дуже близькі до borgbackup, але навантаження на процесор більш високе (працює кілька потоків) і пилкоподібне.
Найімовірніше, програма впирається у продуктивність дискової підсистеми на сервері зберігання даних, як це було з rsync. Розмір репозиторію становив 13гб, як й у zbackup чи borgbackup, явних мінусів під час використання цього рішення виявилося.
Результати
За фактом у всіх кандидатів вийшли близькі показники, проте за різну ціну. Найкраще показав себе borgbackup, трохи повільніше - restic, zbackup, ймовірно, не варто починати застосовувати,
а якщо він вже використовується - намагатися міняти на borgbackup або restic.
Висновки
Найперспективнішим рішенням виглядає restic, т.к. саме він має найкраще співвідношення можливостей до швидкості роботи, але поки не поспішатимемо із загальними висновками.
Borgbackup в принципі нічим не гірше, а ось zbackup можливо краще замінити. Щоправда, для забезпечення роботи правила 3-2-1 zbackup досі можна задіяти. Наприклад, крім засобів резервного копіювання на основі (lib)rsync.
Анонс
Резервне копіювання, частина 5: Тестування bacula та veeam backup for linux
Резервне копіювання, частина 6: Порівняння засобів резервного копіювання
Резервне копіювання, частина 7: Висновки
Автор публікації: Павло Демкович
Джерело: habr.com