У цій статті буде проведено порівняння засобів резервного копіювання, але спочатку варто дізнатися, як вони швидко та добре справляються з відновленням даних із резервних копій.
Для простоти порівняння розглядатиметься відновлення з повної резервної копії, тим більше, що цей режим роботи підтримують усі кандидати. Для простоти цифри взяті вже усередненими (середнє арифметичне із кількох запусків). Результати будуть зведені в таблицю, в якій також буде інформація про можливості: наявність веб-інтерфейсу, простота в налаштуванні і роботі, здатність до автоматизації, наявність різних додаткових можливостей (наприклад, перевірка цілісності даних) і т.п. Графіки показуватимуть завантаження сервера, де дані будуть застосовуватися (не сервера для зберігання резервних копій).
Відновлення даних
Як опорну точку використовуватимуться rsync і tar, оскільки найпростіші скрипти зі зняттям резервних копій.
Rsync впорався з тестовим набором даних за 4 хвилини та 28 секунд, показавши
таке навантаження
Процес відновлення уперся в обмеження дискової підсистеми сервера зберігання резервних копій (пилкоподібні графіки). Також чітко видно завантаження одного ядра без особливих проблем (низький iowait та softirq – немає проблем із диском та мережею відповідно). Оскільки дві інші програми, а саме rdiff-backup і rsnapshot, засновані на rsync, а також пропонують як засіб відновлення звичайний rsync, у них буде приблизно такий самий профіль навантаження і час відновлення резервної копії.
Тар впорався трохи швидше, ніж
2 хвилини та 43 секунди:
Повне завантаження системи була вищою в середньому на 20% через зрослий softirq - зросли накладні витрати при роботі мережевої підсистеми.
Якщо архів додатково стиснути, то час відновлення зростає до 3 хвилин 19 секунд
таким навантаженням на основному сервері (розпакування на стороні основного сервера):
Процес розпакування займає обидва процесорні ядра, оскільки працює два процеси. Загалом – очікуваний результат. Також порівняний результат (3 хвилини та 20 секунд) вийшов при запуску gzip на стороні сервера з резервними копіями, профіль навантаження на основному сервері був дуже схожим на запуск tar без компресора gzip (див. попередній графік).
В rdiff-резервна копія можна синхронізувати останню зроблену резервну копію за допомогою звичайного rsync (результати будуть аналогічними), але більш старі резервні копії все одно треба відновлювати за допомогою програми rdiff-backup, яка впоралася з відновленням за 17 хвилин та 17 секунд, показавши
таке навантаження:
Можливо так і було задумано, принаймні для обмеження швидкості автори . Сам процес відновлення резервної копії займає трохи менше половини одного ядра, з пропорційно порівнянною продуктивністю (тобто в 2-5 разів повільніше) по диску та мережі з rsync.
Rsnapshot Для відновлення пропонується використовувати звичайний rsync, тому його результати будуть аналогічними. Загалом так воно і вийшло.
Відрижка із завданням відновлення резервної копії впорався за 7 хвилин та 2 секунди з
таким навантаженням:
Відпрацював досить швидко, і, принаймні, набагато зручніше чистого rsync: не треба пам'ятати якісь прапори, простий та інтуїтивний cli-інтерфейс, вбудована підтримка кількох копій, — правда вдвічі повільніше. Якщо дані треба відновлювати з останньої зробленої резервної копії можна скористатися rsync, з невеликими застереженнями.
Приблизно таку ж швидкість та навантаження показала програма Резервний ПК при включенні режиму передачі rsync, розгорнувши резервну копію
7 хвилин та 42 секунди:
А ось в режимі передачі даних з tar BackupPC впорався повільніше: за 12 хвилин і 15 секунд, навантаження по процесору при цьому було загалом нижче
у півтора рази:
Лукавість без шифрування показав трохи кращі результати, впоравшись із відновленням резервної копії за 10 хвилин та 58 секунд. Якщо активувати шифрування за допомогою gpg, час відновлення зростає до 15 хвилин і 3 секунд. Також при створенні репозиторію для зберігання копій можна вказати розмір архіву, який буде використаний під час розбиття потоку вхідних даних. У цілому нині, на звичайних жорстких дисках, як і у зв'язку з однопоточним режимом роботи, особливої різниці немає. Вона, можливо, з'явиться за різних розмірів блоків, коли використовуються гібридні сховища. Навантаження на основному сервері при відновленні було таким:
без шифрування
із шифруванням
Дублікат показав порівнянну швидкість відновлення, впоравшись за 13 хвилин та 45 секунд. Ще близько 5 хвилин зайняла перевірка коректності відновлених даних (загалом близько 19 хвилин). Навантаження при цьому було
досить високою:
Коли шифрування aes активувалося внутрішніми засобами, час відновлення становив 21 хвилину 40 секунд, причому завантаження процесору була максимальною (обидва ядра!) під час відновлення; при перевірці даних був активний лише один потік, що займає одне процесорне ядро. Перевірка даних після відновлення зайняла ті ж 5 хвилин (сумарно майже 27 хвилин).
Результат
Трохи швидше duplicati упорався з відновленням при використанні для шифрування зовнішньої програми gpg, але в цілому відмінності від попереднього режиму мінімальні. Час роботи становив 16 хвилин 30 секунд, з перевіркою даних у 6 хвилин. Навантаження було
такий:
АМАНДА, що використовує tar, впоралася за 2 хвилини 49 секунд, що, в принципі, дуже близько до звичайного tar. Навантаження на систему в принципі
така ж:
При відновленні резервної копії засобами zbackup вийшли такі результати:
шифрування, стиск lzma
Час роботи 11 хвилин та 8 секунд
шифрування aes, стиск lzma
Час роботи 14 хвилин
шифрування aes, стиск lzo
Час роботи 6 хвилин, 19 секунд
В цілому непогано. Все упирається у швидкість процесора на сервері резервного копіювання, що досить чітко видно за часом роботи програми з різними компресорами. З боку сервера резервного копіювання запускався звичайний tar, тому якщо порівняти з ним - відновлення працює в 3 рази повільніше. Можливо, варто перевірити роботу у багатопотоковому режимі, з кількістю потоків більше двох.
BorgBackup в режимі без шифрування впорався трохи повільніше tar, за 2 хвилини 45 секунд, проте, на відміну від того ж tar, з'явилася можливість дедуплікації репозиторію. Навантаження при цьому вийшло
наступною:
Якщо активувати шифрування на основі blake, швидкість відновлення резервної копії трохи сповільнюється. Час відновлення в цьому режимі 3 хвилини 19 секунд, а навантаження вийшло
така:
Шифрування aes працює трохи повільніше, час відновлення 3 хвилини 23 секунди, навантаження особливо
не змінилася:
Оскільки Borg може працювати в багатопотоковому режимі - завантаження процесора максимальне, при цьому при активації додаткових функцій просто зростає час роботи. Очевидно, варто досліджувати багатопоточність роботи аналогічно zbackup.
Рестик впорався з відновленням трохи повільніше, час роботи становив 4 хвилини 28 секунд. Навантаження при цьому виглядало
так:
Очевидно, процес відновлення працює в кілька потоків, але ефективність не така висока, як у BorgBackup, але порівняно за часом зі звичайним rsync.
За допомогою urBackup вдалося відновити дані за 8 хвилин і 19 секунд, навантаження при цьому було
такий:
Так само видно не дуже високе навантаження, навіть нижче, ніж у tar. Місцями сплески, але не більше завантаження одного ядра.
Вибір та обґрунтування критеріїв для порівняння
Як було сказано в одній із попередніх статей, система резервного копіювання повинна відповідати наступним критеріям:
- Простота у роботі
- Універсальність
- Стабільність
- швидкість
Варто розглянути кожен пункт окремо детальніше.
Простота роботи
Найкраще, коли є одна кнопка «Зробити все добре», але якщо повернутися до реальних програм — найзручніше буде певний звичний та стандартний принцип роботи.
Більшості користувачів, найімовірніше, буде краще, якщо не треба запам'ятовувати купу ключів для cli, налаштовувати купу різних, найчастіше малозрозумілих опцій через web або tui, налаштовувати оповіщення про невдалу роботу. Сюди відноситься можливість легко «вписати» рішення для резервного копіювання в існуючу інфраструктуру, а також автоматизація процесу резервного копіювання. Тут же можливість встановлення пакетним менеджером, або в одну-дві команди виду «завантажити та розпакувати». curl ссылка | sudo bash - Складний метод, оскільки треба перевірити, що прилітає за посиланням.
Наприклад, з розглянутих кандидатів простим рішенням є burp, rdiff-backup і restic, що мають ключі, що менімонічно запам'ятовуються, для різних режимів роботи. Трохи складнішим – borg та duplicity. Найскладнішим була AMANDA. Інші за простотою використання десь посередині. У будь-якому випадку, якщо треба більше 30 секунд на читання посібника користувача, або треба сходити в Google або інший пошуковик, а також перегорнути довге простирадло help - рішення складне, так чи інакше.
Частина розглянутих кандидатів вміють автоматично надіслати повідомлення по e-mailjabber, інші покладаються на налаштовані оповіщення в системі. При цьому найчастіше складні рішення мають не зовсім очевидні налаштування оповіщень. У будь-якому разі, якщо програма зняття резервної копії видасть ненульовий код повернення, який буде правильно зрозумілий системним сервісом періодичних завдань (відлетить повідомлення системному адміністратору або одразу на моніторинг) — ситуація проста. А от якщо система резервного копіювання, яка працює не на сервері резервних копій, не може без налаштування, очевидним способом сказати про проблему — складність вже надмірна. У будь-якому випадку видача попереджень та інших повідомлень лише у веб-інтерфейс або в журнал — погана практика, оскільки найчастіше вони будуть проігноровані.
Що ж до автоматизації — найпростіша програма вміє читати змінні оточення, що задають її режим роботи, чи має розвинений cli, здатний повністю дублювати поведінка під час роботи через веб-інтерфейс, наприклад. Сюди відноситься можливість потокової роботи, наявність можливостей для розширення і т.п.
Універсальність
Частково перегукується з попереднім підрозділом щодо автоматизації, не повинно бути особливою проблемою «вписати» процес резервного копіювання в існуючу інфраструктуру.
Слід зазначити, що використання нестандартних портів (ну крім веб-інтерфейсу) для роботи, реалізація шифрування нестандартним способом, обмін даними нестандартним протоколом – ознаки неуніверсального рішення. Здебільшого, всі кандидати так чи інакше їх мають з очевидної причини: простота та універсальність зазвичай не сумісні. Як виняток - burp, є й інші.
Як ознака – можливість роботи використовуючи звичайний ssh.
Швидкість роботи
Найсуперечливіший і спірніший пункт. З одного боку, запустили процес, він відпрацював максимально швидко і не заважає основним завданням. З іншого боку — сплеск трафіку та навантаження на процесор на час резервного копіювання. Ще варто відзначити, що найшвидші програми для зняття копій зазвичай найбідніші за функціями, важливими для користувачів. Знову ж таки: якщо для того, щоб дістати один нещасний текстовий файл розміром кілька десятків байт з паролем, а через нього стоїть весь сервіс (так-так, я розумію, що тут процес резервного копіювання найчастіше не винен), і треба перечитати послідовно всі файли в репозиторії або розгорнути цілий архів — система резервного копіювання ніколи не швидка. Ще один пункт, який часто стає каменем спотикання, — швидкість розгортання резервної копії з архіву. Тут явна перевага у тих, хто може просто скопіювати або перемістити файли в потрібне місце без особливих маніпуляцій (rsync, наприклад), але найчастіше проблему треба вирішувати організаційним способом, емпіричним шляхом: вимірювати час відновлення резервної копії та відкрито про це повідомляти користувачів.
Стабільність
Слід розуміти так: з одного боку, має бути можливість розвернути назад резервну копію по-любому, з іншого — стійкість до різних проблем: урвища мережі, відмова диска, видалення частини репозиторію.
Порівняння засобів резервного копіювання
Час створення копії
Час відновлення копії
проста установка
Просте налаштування
просте використання
Проста автоматизація
Чи потрібний клієнт сервер?
Перевірка цілісності репозиторію
Різноманітні копії
Робота через pipe
Універсальність
самостійність
Прозорість репозиторію
Шифрование
стиснення
Дедуплікація
Web-інтерфейс
Заливка у хмару
Підтримка Windows
бал
Rsync
4м15с
4м28с
да
немає
немає
немає
да
немає
немає
да
немає
да
да
немає
немає
немає
немає
немає
да
6
Тар
чистий
3м12с
2м43с
да
немає
немає
немає
немає
немає
да
да
немає
да
немає
немає
немає
немає
немає
немає
да
8,5
gzip
9м37с
3м19с
да
Rdiff-backup
16м26с
17м17с
да
да
да
да
да
немає
да
немає
да
немає
да
немає
да
да
да
немає
да
11
Rsnapshot
4м19с
4м28с
да
да
да
да
немає
немає
да
немає
да
немає
да
немає
немає
да
да
немає
да
12,5
Відрижка
11м9с
7м2с
да
немає
да
да
да
да
да
немає
да
да
немає
немає
да
немає
да
немає
да
10,5
Лукавість
no encryption
16м48с
10м58с
да
да
немає
да
немає
да
да
немає
немає
да
немає
да
да
немає
да
немає
да
11
gpg
17м27с
15м3с
Дублікат
no encryption
20м28с
13м45с
немає
да
немає
немає
немає
да
да
немає
немає
да
немає
да
да
да
да
да
да
11
АЕС
29м41с
21м40с
gpg
26м19с
16м30с
zbackup
no encryption
40м3с
11м8с
да
да
немає
немає
немає
да
да
да
немає
да
немає
да
да
да
немає
немає
немає
10
АЕС
42м0с
14м1с
aes+lzo
18м9с
6м19с
BorgBackup
no encryption
4м7с
2м45с
да
да
да
да
да
да
да
да
да
да
немає
да
да
да
да
немає
да
16
АЕС
4м58с
3м23с
blake2
4м39с
3м19с
Рестик
5м38с
4м28с
да
да
да
да
немає
да
да
да
да
да
немає
да
немає
да
немає
да
да
15,5
urBackup
8м21с
8м19с
да
да
да
немає
да
немає
да
немає
да
да
немає
да
да
да
да
немає
да
12
Аманда
9м3с
2м49с
да
немає
немає
да
да
да
да
немає
да
да
да
да
да
немає
да
да
да
13
Резервний ПК
rsync
12м22с
7м42с
да
немає
да
да
да
да
да
немає
да
немає
немає
да
да
немає
да
немає
да
10,5
дьоготь
12м34с
12м15с
Легенда таблиці:
- Зелений, час роботи менше п'яти хвилин, або відповідь «Так» (крім стовпця «Потрібен клієнт-сервер?»), 1 бал
- Жовтий, час роботи 0.5-XNUMX хвилин, XNUMX бала
- Червоний, час роботи більше десяти хвилин, або відповідь «Ні» (крім стовпця «Потрібен клієнт-сервер?»), 0 балів
Згідно з наведеною вище таблицею найбільш простим, швидким, а разом з тим зручним і потужним інструментом для резервного копіювання є BorgBackup. Друге місце посів Restic, решта розглянутих кандидатів розмістилася приблизно однаково з розкидом в один-два бали наприкінці.
Дякую всім, хто дочитав цикл до кінця, пропоную обговорити варіанти, запропонувати свої, якщо є. У міру обговорення таблицю можна доповнити.
Результатом циклу стане заключна стаття, в якій буде спроба вивести ідеальний, швидкий і керований засіб для резервного копіювання, що дозволяє в найкоротші терміни розгорнути копію і разом з тим мати зручність і простоту в налаштуванні та супроводі.
Анонс
Резервне копіювання, частина 6: Порівняння засобів резервного копіювання
Резервне копіювання, частина 7: Висновки
Джерело: habr.com