Действительно ли периодические полные резервные копии действительно необходимы при настройке инкрементного резервного копирования?

Question

Я намерен использовать старый компьютер, который у меня есть, в качестве удаленного сервера резервного копирования для себя и нескольких других людей. Мы все географически разделены, и мы планируем делать ежедневные инкрементные резервные копии, используя rsync и ssh.

Моя первоначальная идея состояла в том, чтобы сделать одну первоначальную полную резервную копию, чтобы больше никогда не приходилось сталкиваться с накладными расходами на ее выполнение, и с этого момента копировать только файлы, измененные с момента последней резервной копии.

Мне сказали, что это может быть плохо, но я не понимаю, почему. Поскольку каждый снимок состоит из жестких ссылок на неизмененные файлы плюс оригинальные измененные, не будет ли это идентично новой полной резервной копии? Зачем мне делать еще одну полную резервную копию?

РЕДАКТИРОВАТЬ:

Я должен был объяснить пункт лучше. Когда я имею в виду, что собираюсь делать инкрементные резервные копии с помощью rsync, я имею в виду это:

rsync -avh --delete --link-dest=./remote/previous_increment ./local/ ./remote/new_increment

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

Что делать, если я периодически делаю синтетическое полное резервное копирование на стороне сервера, ломая ссылки на последнем снимке и копируя его на другой защищенный от записи HD (скажем, раз в месяц). Таким образом, у меня будет избыточная полная копия, и я все равно буду избегать повторной отправки файлов.

Это решит проблему? Нужно ли мне делать полные резервные копии?

Answer 1

Обычно, если вы делаете инкрементное резервное копирование, вы сохраняете только фактически измененные файлы (например, архив tar), в то время как у вас есть неизмененные файлы только в более ранних файлах резервных копий. Таким образом, вам понадобятся все резервные файлы для восстановления, и вы никогда не сможете удалить старые резервные копии. Поскольку это практически невозможно, через некоторое время вам нужно будет сделать новые полные резервные копии.

То, что вы используете, является более продвинутым (rsnapshot?), Где вы всегда храните полный набор данных, но минимизируете накладные расходы, обмениваясь данными между резервными копиями с помощью жестких ссылок. Таким образом, вы можете удалить старые резервные копии без аннулирования текущих. Так что обычный аргумент не считается.

Редактировать:

rsnapshot работает так:

В первый раз он просто создает полную копию, используя rsync.

Любая резервная копия после этого создает новое полное дерево каталогов, где все файлы являются жесткими ссылками на предыдущую резервную копию. После этого измененные файлы заменяются запуском rsync над этим деревом.

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

Затраты на резервное копирование - это дополнительное дерево каталогов, которое, конечно, тоже использует некоторое пространство. Но вы можете удалить старые деревья резервных копий, не затрагивая остальные, чтобы восстановить это пространство.

Описание вашей стратегии резервного копирования звучит как rsnapshot для меня.

Edit2:

Если вас беспокоит бит-гниль - то есть существующие файлы резервных копий повреждены - вы можете добавить опцию -c к rsync, которая создает контрольные суммы MD5 для локальных и удаленных файлов. Это значительно увеличит дисковый ввод-вывод, поскольку каждый файл должен быть прочитан. Но сетевой трафик увеличивается незначительно, так как только контрольные суммы каждого файла должны передаваться дополнительно. Это устранит последнюю причину новой полной резервной копии.

Answer 2

Инкрементное резервное копирование, т.е. использование rsync , является более сложным процессом, чем статическое резервное копирование, т.е. использование cp . Некоторые люди считают, что добавочное резервное копирование с большей вероятностью будет повреждено.

1. Ошибка может быть в самом инструменте; Известно, что rsync в Windows является нестабильным и иногда удаляет файлы из резервной копии, когда этого не следует делать .

2. Если средство резервного копирования хранит только двоичное различие между версиями файла, то потеря промежуточной версии файла может сделать невозможным восстановление окончательной версии файла.

---

Каким бы ни было ваше решение для резервного копирования, регулярно проверяйте его , восстанавливая копию ваших данных из резервной копии.

Answer 3

Я думаю, что было недопонимание.

В большинстве случаев, когда я слышу полное резервное копирование и добавочное резервное копирование, люди имеют в виду
Полный: резервное копирование всех данных.
Инкрементный: резервное копирование только изменений.

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

Теперь rsync обычно не делает частичные резервные копии. Если отправляет только изменения по сети, но конечным результатом является полная копия всех данных. Таким образом, наиболее часто используемая причина не использовать только частичные значения не применяется.

Обратите внимание, что желательно иметь как минимум две резервные копии. Один известный хороший и рабочий экземпляр. Либо чередуйте их, либо создайте и протестируйте годовую резервную копию, установите ее только для чтения и используйте другую резервную копию до следующего года. Тогда повторите.