Ця оглядова нотатка продовжує , написана на прохання читачів, в ній йтиметься про UrBackup, BackupPC, а також AMANDA.
Огляд UrBackup.
На прохання учасника додаю огляд UrBackup, клієнт-серверної системи для резервного копіювання. Вона дозволяє створювати повні та інкрементальні резервні копії, вміє працювати зі знімками пристроїв (Win only?), а також вміє створювати файлові резервні копії. Клієнт може перебувати як у одній мережі із сервером, і підключатися через Internet. Заявлено відстеження змін, що дозволяє швидко знайти різницю між резервними копіями. Також є підтримка дедуплікації зберігання даних на стороні сервера, що дозволяє економити місце. Мережеві з'єднання шифруються, також є web-інтерфейс для керування сервером. Давайте подивимося, на що вона здатна:
У режимі створення повної резервної копії вийшли такі результати:
Час роботи:
Перший запуск
Другий запуск
Третій запуск
Перший тест
8м20с
8м19с
8м24с
Другий тест
8м30с
8м34с
8м20с
Третій тест
8м10с
8м14с
8м12с
У режимі створення інкрементальних резервних копій:
Час роботи:
Перший запуск
Другий запуск
Третій запуск
Перший тест
8м10с
8м10с
8м12с
Другий тест
3м50с
4м12с
3м34с
Третій тест
2м50с
2м35с
2м38с
Розмір репозиторію в обох випадках становив приблизно 14 гб, що говорить про дідуплікацію, що працює на стороні сервера. Також слід відзначити невідповідність часу створення резервної копії на сервері та на клієнті, що досить чітко видно за графіками і є дуже приємним бонусом, оскільки web-інтерфейс показує час роботи процесу резервного копіювання на стороні сервера без урахування
стану клієнта. Загалом графіки для повної та інкрементальної копії не відрізняються. Ймовірно, відмінність лише тому, як це обробляється за сервера. Також порадувало низьке завантаження процесора на системі, що резервується.
Огляд BackupPC
На прохання учасника додаю огляд BackupPC. Дане ПЗ встановлюється на сервер зберігання резервних копій, написане на perl, працює поверх різних засобів резервного копіювання - насамперед rsync, tar. Як транспорт використовується ssh і smb, також є web-інтерфейс на основі cgi (розгортається поверх apache). У web-інтерфейсі є великий перелік налаштувань. З особливостей — наявність можливості завдання мінімального часу між резервними копіями, а також періоду, протягом якого резервні копії не створюватимуться. При виборі файлової системи для сервера резервного копіювання слід стежити за підтримкою жорстких посилань. Таким чином файлову систему для сховища не розіб'єш на точки монтування. В цілому, досить приємне враження, давайте подивимося, на що здатне це програмне забезпечення:
У режимі створення повних резервних копій з rsync вийшли такі результати:
Перший запуск
Другий запуск
Третій запуск
Перший тест
12м25с
12м14с
12м27с
Другий тест
7м41с
7м44с
7м35с
Третій тест
10м11с
10м0с
9м54с
Якщо ж використовувати повні резервні копії та tar:
Перший запуск
Другий запуск
Третій запуск
Перший тест
12м41с
12м25с
12м45с
Другий тест
12м35с
12м45с
12м14с
Третій тест
12м43с
12м25с
12м5с
У режимі створення інкрементальних резервних копій довелося відмовитись від tar, оскільки за таких налаштувань резервні копії не створювалися.
Результати створення резервних копій інкрементальних з використанням rsync такі:
Перший запуск
Другий запуск
Третій запуск
Перший тест
11м55с
11м50с
12м25с
Другий тест
2м42с
2м50с
2м30с
Третій тест
6м00с
5м35с
5м30с
Загалом видно невелику перевагу за швидкістю у rsync, також rsync економніше працює з мережею. Почасти це може бути компенсовано меншим використанням cpu з tar як програма для створення резервних копій. Іншою перевагою rsync є робота з інкрементальними копіями. Розмір репозиторію при створенні повних резервних копій однаковий становить 16 гб, у разі інкрементальних копій — 14 гб за один прогін, що означає дідуплікацію, що працює.
Огляд AMANDA
На прохання учасника додаю тести AMANDA,
Результати тестового прогону з tar як архіватор та активація стиснення такі:
Перший запуск
Другий запуск
Третій запуск
Перший тест
9м5с
8м59с
9м6с
Другий тест
0м5с
0м5с
0м5с
Третій тест
2м40с
2м47с
2м45с
Програма повністю завантажує одне процесорне ядро, але через обмежений по iops диск на стороні сервера зберігання резервних копій не може розвинути велику швидкість передачі даних. В цілому, налаштування завдало трохи більше клопоту, ніж у інших учасників, оскільки автор програми не використовує як транспорт ssh, а реалізує схожу схему з ключами, створюючи і підтримуючи повноцінну CA. Є можливість широко обмежити клієнта і сервер резервного копіювання: наприклад, якщо вони не можуть повністю довіряти один одному, то можна як варіант заборонити ініціювання відновлення резервної копії з боку сервера, задаючи значення відповідної змінної в нуль у файлі налаштувань. Можна підключити web-інтерфейс для управління, але в цілому налаштовану систему можна автоматизувати повністю за допомогою невеликих скриптів на bash (або SCM, наприклад ansible). Існує дещо нетривіальна система налаштування сховища, що, мабуть, пов'язано з підтримкою великого списку різних пристроїв для зберігання даних (касети LTO, жорсткі диски тощо). Також варто відзначити, що з усіх програм, розглянутих у цій статті, AMANDA – єдина, яка змогла виявити перейменування каталогу. Розмір репозиторію при одному прогоні становив 13 гб.
Анонс
Резервне копіювання, частина 6: Порівняння засобів резервного копіювання
Резервне копіювання, частина 7: Висновки
Джерело: habr.com