Назад | Перейти на главную страницу

Стратегия создания инкрементных резервных копий

В настоящее время я создаю резервную копию своих личных файлов с помощью простого сценария оболочки, который создает архив. Он запускается cron ежечасно.

Я планирую перейти на инкрементное резервное копирование (я буду использовать дублирование), потому что это минимизирует передачу данных по сети.

Это подводит меня к некоторым общим вопросам:

Правильный ответ зависит от таких вопросов, как:

  1. Сколько места доступно на вашем устройстве резервного копирования
  2. Как долго вы хотите хранить резервные копии?
  3. Как часто меняются ваши данные?
  4. Что такое «Скорость изменения» (сколько данных изменится между полными резервными копиями?) Я читал, что скорость изменения 5% типична для многих предприятий. Ваши личные файлы могут быть более или менее частыми.

Если у вас нет особых потребностей, постарайтесь придерживаться простого расписания. Сложные расписания резервного копирования могут вызвать путаницу во время восстановления, и вам не нужно больше путаницы во время восстановления.

Многие продукты резервного копирования предлагают простое расписание резервного копирования по умолчанию, подобное приведенному ниже. Это можно легко адаптировать к вашим будущим потребностям.

  • Месячные полные, хранятся в течение 1 года. Совершено в воскресенье.
  • Еженедельные полные, держите 1 месяц. Совершено в воскресенье.
  • Дневные приращения, выдерживать 2 недели.

  • Ежечасные нарастающие звуки слишком часты для большинства людей, поскольку файлы меняются не так часто.

Инкрементное резервное копирование - это полный PITA, и его по возможности следует избегать.

Если пропускная способность сети действительно является проблемой, я бы порекомендовал сохранить зеркало в другом месте и реплицировать из источника с помощью rsync / unison, а затем создать согласованный архив обновленного образа в месте назначения.