Можно ли использовать жесткие ссылки для дедупликации резервных копий?

Question

Я знаю о полных резервных копиях, инкрементных и декрементных. Однако мне было интересно, почему никто (Windows Backup, TrueImage, Paragon), по-видимому, не реализовал следующий алгоритм резервного копирования.

Для этого требуется резервный носитель с поддержкой ссылок, например NTFS. В идеале носитель резервного копирования должен быть одного формата, чтобы поддерживать все функции, такие как альтернативные потоки данных (ADS).

1. Первая резервная копия - полная резервная копия. Это скопирует все файлы на резервный носитель в подпапку \. Давайте назовем эту папку L (для "последней"). Там нет специального формата файлов, просто скопируйте файлы.
2. При следующей резервной копии будет создана новая подпапка \, назовем ее C (для "текущей"). Файлы, которые изменились из полной резервной копии, будут снова скопированы с исходного диска. Файлы, которые не изменились, перемещаются из L в C, и создается жесткая ссылка, указывающая из L в C.
3. При повторном резервном копировании та же процедура будет применяться с C и другой новой папкой.

Есть ли что-то, что я пропускаю в этом алгоритме, который не будет работать?

Хотя я все же заметил какие-либо проблемы, я вижу следующие преимущества:

• последняя резервная копия (С) всегда является полной резервной копией. Для восстановления резервной копии вам нужна только эта резервная копия. Пользователь может удалить любую старую резервную копию, не разрушая возможности восстановления (что не относится к полному, инкрементному и декрементному резервному копированию).
• Старые резервные копии будут работать как полные резервные копии благодаря ссылкам, но занимают гораздо меньше места на диске.
• есть полная история изменений файла, если пользователь не удалил файл. Но в отличие от SVN, можно удалить старые ревизии.
• Перемещение файлов и создание ссылок - очень быстрые операции. Создание резервной копии должно быть соответственно производительным.
• Можно выборочно удалять измененные файлы в старых резервных копиях (например, только большие), не удаляя полную резервную копию

Answer 1

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

Я бы изменил формулировку "перешел из L в C", чтобы просто сказать "жестко связан с L в C".

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

Answer 2

То, что вы описываете, уже используется, с rsync и его --link-dest= , через десятки программ- оболочек , таких как dirvish , среди других.

Answer 3

То, что вы описываете, по сути является схемой инкрементного резервного копирования.

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

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

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

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

Answer 4

Я думаю, что это в основном то, что вы называете Delorean-копией. Например, есть расширение Link Shell для Windows, которое реализует это поведение. У них есть довольно хорошее объяснение в их документации:

http://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html#deloreancopy