Повний термін експлуатації та ефективність резервного копіювання

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

Чи розумно бажати повного резервного копіювання так часто? З моменту збільшення дублікату вперед, кожна додаткова резервна копія покладається на попередній приріст, і всі сильно покладаються на останню повну резервну копію. Якщо це стане корумпованим, трапляться погані речі. Питання, пов’язане з цим: чи перевіряє дублікатність додаткового резервного копіювання на узгодженість?

Припускаючи , що я дійсно хочу , повне резервне копіювання кожен так часто, наскільки ефективно це лукавство створити цю повну резервну копію? Чи може він перевіряти підписи файлів і копіювати незмінені дані з попередніх повних резервних копій / збільшення? В основному створення нового "повного" архіву для передачі нових / змінених даних та об'єднання існуючих незмінних даних?

На даний момент я занепокоєний тим, що потрібна робота з повною резервною копією, але послідовне велике використання пропускної здатності повних резервних копій зробить це необґрунтованим для деяких клієнтів.

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

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

Я не думаю, що у дублікаті конкретно є команда "перевірка" http://pad.lv/660895 , але було б добре, якби це було. Дуже доцільно робити тест-відновлення кожен так часто.

Пов'язане питання - чи слід тримати більше одного резервного ланцюга. Знову ж таки, це залежить від вартості. Однією з причин, щоб утримати одну, є те, що ви могли відновити з неї, якщо поточна ланцюг пошкоджена, або через збій апаратури, збій ОС або помилку дублікату. Звичайно, якщо стара ланцюг дуже стара, відновлення з неї може мати обмежене значення.

Створення повної резервної копії завжди завантажує повну копію даних.

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

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

Я не знайомий з Duplicity, але на їхньому веб-сайті, схоже, не робляться синтетичні повні резервні копії. Ви повинні зберегти всі частки приросту в повному обсязі, на якому вони засновані. Якщо це так, ви, ймовірно, хочете примусово створювати повне резервне копіювання так часто, оскільки:

• Пройшовши мільйон приростів, ймовірно, відновлення буде повільним
• Напевно, ви не хочете, щоб додаткові частки поверталися до початку часу

Один цікавий спосіб досягти синтетичного палива - це використовувати rsync за допомогою параметра --link-dest = DIR або використовувати rsnapshot . Він зберігатиме лише відмінності між кожною додатковою резервною копією, але кожна, здається, буде повною. Коли ви видалите будь-який з них, він автоматично об'єднає додаткові розміри. Це робиться за допомогою магії жорстких посилань, тож diff буде на основі файлів (або файл змінився і включений у diff, або ні).