У цій нотатці розглянуто засоби резервного копіювання, які виконують резервне копіювання шляхом створення архівів на резервному сервері.
З тих, які задовольняють вимогам – duplicity (до якого є приємний інтерфейс у вигляді deja dup) та duplicati.
Ще один вельми примітний засіб резервного копіювання — dar, але оскільки він має дуже великий список опцій — методика тестування покриває навряд чи 10% від того, на що він здатний, — його в рамках поточного циклу не тестуємо.
Очікувані результати
Оскільки обидва кандидати так чи інакше створюють архіви, то як орієнтир можна використовувати звичайний tar.
Додатково оцінимо, наскільки добре оптимізується зберігання даних на сервері зберігання шляхом створення резервних копій, що містять лише різницю між повною копією та поточним станом файлів, або між минулим та поточним архівами (інкрементальні, декрементальні тощо).
Поведінка під час створення резервних копій:
- Порівняно невелика кількість файлів на сервері зберігання резервних копій (порівняно з кількістю резервних копій або розміром даних у гігабайтах), але досить великий їх розмір (десятки-сотні мегабайт).
- Розмір репозиторію включатиме лише зміни - дублікати не зберігатимуться, таким чином розмір репозиторію буде меншим, ніж при роботі ПЗ на основі rsync.
- Очікується велике навантаження на процесор при використанні стиснення та/або шифрування, а також, ймовірно, досить велике навантаження на мережу та дискову підсистему, якщо процес архівації та/або шифрування працюватиме на сервері зберігання резервних копій.
Як еталонне значення запустимо наступну команду:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Результати виконання вийшли такі:
Час виконання 3m12s. Видно, що швидкість уперлася в дискову підсистему сервера зберігання резервних копій, як і в прикладі . Тільки трохи швидше, т.к. запис йде до одного файлу.
Також для оцінки стиснення запустимо той самий варіант, але включимо стиск на стороні сервера резервного копіювання:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Результати такі:
Час виконання 10м11с. Найімовірніше, вузьке місце — однопоточний компресор на стороні, що приймає.
Та ж команда, але з перенесенням стиснення на сервер із вихідними даними для перевірки гіпотези, що вузьке місце – однопоточний компресор.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Вийшло так:
Час виконання становив 9m37s. Очевидно видно завантаження одного ядра компресором, т.к. швидкість передачі по мережі та навантаження на дискову підсистему джерела - аналогічні.
Для оцінки шифрування можна використовувати openssl або gpg, підключаючи додаткову команду openssl або gpg у pipe. Для орієнтиру буде така команда:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Результати вийшли такі:
Час виконання вийшов 10m30s, оскільки запущено 2 процеси на стороні, що приймає, - вузьке місце знову однопоточний компресор, плюс невеликі накладні витрати на шифрування.
UPD: На прохання bliznezz додаю випробування з pigz. Якщо використовувати тільки компресор - вийшло за 6m30s, якщо додати ще й шифрування - приблизно 7m. Провал на нижньому графіці - непорушений дисковий кеш:
Тестування duplicity
Duplicity — програмне забезпечення для python для резервного копіювання шляхом створення шифрованих архівів у форматі tar.
Для інкрементальних архівів застосовується librsync, отже, очікується поведінки, описаного в .
Резервні копії можуть шифруватися та підписуватися за допомогою gnupg, що важливо при використанні різних провайдерів для зберігання резервних копій (s3, backblaze, gdrive тощо)
Подивимося, які будуть результати:
Ось такі результати вийшли під час запуску без шифрування.
спойлер
Час роботи кожного тестового запуску:
Запуск 1
Запуск 2
Запуск 3
16м33с
17м20с
16м30с
8м29с
9м3с
8м45с
5м21с
6м04с
5м53с
А ось результати при включенні шифрування gnupg з розміром ключа 2048 біт:
Час роботи на тих же даних із шифруванням:
Запуск 1
Запуск 2
Запуск 3
17м22с
17м32с
17м28с
8м52с
9м13с
9м3с
5м48с
5м40с
5м30с
Було вказано розмір блоку - 512 мегабайт, що чітко видно на графіках; завантаження процесора фактично трималася лише на рівні 50%, отже, програма утилізує трохи більше одного процесорного ядра.
Також досить добре видно принцип роботи програми: взяли шматочок даних, потиснули його, відправили на сервер зберігання резервних копій, який може бути досить повільним.
Ще одна особливість – передбачуваний час роботи програми, який залежить лише від розміру змінених даних.
Включення шифрування не особливо збільшило час роботи програми, але підвищило завантаження процесора приблизно на 10%, що може бути непоганим приємним бонусом.
На жаль, дана програма не змогла коректно виявити ситуацію з перейменуванням каталогу, і результуючий розмір репозиторію дорівнював розміру змін (тобто всі 18гб), але можливість використовувати недовірений сервер для резервного копіювання однозначно перекриває таку поведінку.
Тестування duplicati
Це програмне забезпечення написано на C#, запускається за допомогою набору бібліотек від Mono. Є GUI, а також cli версія.
Приблизний список основних можливостей близький до duplicity, включаючи різних провайдерів для зберігання резервних копій, проте, на відміну від duplicity, більшість можливостей доступна без сторонніх коштів. Плюс це чи мінус — залежить від конкретної нагоди, проте для новачків, найімовірніше, простіше мати перед очима список відразу всіх можливостей, ніж довстановлювати пакети для python, як у випадку з duplicity.
Ще один невеликий нюанс — програма активно пише локальну базу sqlite від імені користувача, який запускає резервне копіювання, тому потрібно додатково стежити за коректним зазначенням потрібної бази при кожному запуску процесу використовуючи cli. Під час роботи через GUI або WEBGUI деталі будуть приховані від користувача.
Давайте подивимося, які показники може видати це рішення:
Якщо вимкнути шифрування (причому WEBGUI цього не рекомендує), результати такі:
Час роботи:
Запуск 1
Запуск 2
Запуск 3
20м43с
20м13с
20м28с
5м21с
5м40с
5м35с
7м36с
7м54с
7м49с
З увімкненим шифруванням, використовуючи aes, виходить так:
Час роботи:
Запуск 1
Запуск 2
Запуск 3
29м9с
30м1с
29м54с
5м29с
6м2с
5м54с
8м44с
9м12с
9м1с
А якщо використовувати зовнішню програму gnupg, виходять такі результати:
Запуск 1
Запуск 2
Запуск 3
26м6с
26м35с
26м17с
5м20с
5м48с
5м40с
8м12с
8м42с
8м15с
Як бачимо — програма вміє працювати в кілька потоків, але від цього не є більш продуктивним рішенням, а якщо порівнювати роботу шифрування — запуск зовнішньої програми
вийшов швидше, ніж застосування бібліотеки з набору Mono. Можливо, це пов'язано з тим, що зовнішню програму більше оптимізовано.
Приємним моментом став той факт, що розмір репозиторію займає рівно стільки, скільки реально було змінених даних, тобто. duplicati виявив перейменування каталогу і коректно опрацював цю ситуацію. Це можна побачити під час прогону другого тесту.
Загалом досить позитивні враження від програми, включаючи достатню доброзичливість до новачків.
Результати
Обидва кандидати досить неспішно відпрацювали, але загалом, у порівнянні зі звичайним tar, є прогрес як мінімум у duplicati. Ціна такого прогресу також зрозуміла - помітне навантаження
процесора. Загалом ніяких особливих відхилень при прогнозуванні результатів немає.
Висновки
Якщо нікуди поспішати не потрібно, а також є запас по процесору - підійде будь-яке з розглянутих рішень, принаймні виконано досить велику роботу, яку не варто повторювати шляхом написання скриптів-оберток поверх tar. Наявність шифрування дуже потрібна властивість, якщо сервер для зберігання резервних копій не може бути повністю довіреним.
Якщо порівнювати з рішеннями на основі — продуктивність може бути гіршою в кілька разів, незважаючи на те, що у чистому вигляді tar відпрацював швидше за rsync на 20-30%.
Економія на розмірі репозиторію є, але тільки у duplicati.
Анонс
Резервне копіювання, частина 3: Огляд та тестування duplicity, duplicati, deja dup
Резервне копіювання, частина 4: Огляд та тестування zbackup, restic, borgbackup
Резервне копіювання, частина 5: Тестування bacula та veeam backup for linux
Резервне копіювання, частина 6: Порівняння засобів резервного копіювання
Резервне копіювання, частина 7: Висновки
Автор публікації: Павло Демкович
Джерело: habr.com