Я пытаюсь разработать стратегию резервного копирования для некоторых клиентов и склоняюсь к дублированию для удаленного резервного копирования (уже использую rdiff-backup для внутренних / локальных резервных копий).
Разумно ли время от времени запрашивать полную резервную копию? Поскольку дублирование увеличивается вперед, каждое добавочное резервное копирование полагается на предыдущее приращение, и все в значительной степени полагаются на последнее полное резервное копирование. Если это станет коррумпированным, произойдут плохие вещи. Связанный вопрос: Проверяет ли Duplicity инкрементные резервные копии на согласованность?
Предполагая, что я делать нужно время от времени делать полную резервную копию, насколько эффективно дублирование создает полную резервную копию? Может ли он проверять подписи файлов и копировать неизмененные данные из предыдущих полных резервных копий / приращений? В основном создание нового «полного» архива, в котором передаются новые / измененные данные и объединяются существующие неизмененные данные?
Сейчас меня беспокоит необходимость запуска полного резервного копирования, но постоянное использование большой пропускной способности для полных резервных копий сделает это нецелесообразным для некоторых клиентов.
Я думаю, что разумно время от времени запрашивать полную резервную копию: большинство моих машин настроено на создание резервной копии каждые несколько месяцев. В этом числе нет ничего волшебного: правильное значение будет зависеть от того, сколько у вас данных, как быстро они меняются, насколько вероятно, что вы захотите восстановить что-либо, кроме самого последнего снимка, сколько вам обходится трафик и хранилище. , и как ты параноик. Другим людям может потребоваться полная резервная копия каждую неделю.
Если вы не выполняете время от времени полное резервное копирование, размер архива и время восстановления будут продолжать расти.
Я не думаю, что у двуличия есть команда "проверить" http://pad.lv/660895, но было бы неплохо, если бы это было так. Очень благоразумно время от времени проводить тестовое восстановление.
С этим связан вопрос, следует ли хранить более одной цепочки резервных копий. Опять же, это зависит от стоимости. Одна из причин сохранить один - это то, что вы можете восстановить его, если текущая цепочка повреждена либо из-за аппаратного сбоя, сбоя ОС, либо из-за ошибки дублирования. Конечно, если старая цепь очень старая, восстановление из нее может иметь ограниченную ценность.
При создании полной резервной копии всегда выгружается полная копия данных.
Если клиент интересует только часть используемой полосы пропускания, а не плата за трафик, вы можете запустить ее, например, trickle.
То, о чем вы просите, называется синтетическая полная резервная копия, который относится к процессу получения полной резервной копии путем объединения инкрементной резервной копии с предыдущей полной резервной копией на стороне назначения (т. е. на сервере резервного копирования).
Я не знаком с Duplicity, но из их сайт похоже, что он не делает синтетических полных резервных копий. Вы должны сохранить все инкременты в полном объеме, на котором они основаны. Если это является В этом случае вы, вероятно, захотите периодически создавать полную резервную копию, потому что:
Один интересный способ добиться синтетической наполненности - использовать rsync с параметром --link-dest = DIR вариант или используйте rsnapshot. Он будет хранить только различия между каждой инкрементной резервной копией, но каждая из них будет выглядеть полной. Когда вы удаляете любой из них он автоматически объединит инкрементальные числа соответствующим образом. Он делает это с помощью магии жестких ссылок, поэтому различия будут основаны на файлах (либо файл был изменен и включен в diff, либо нет).