Инкрементные резервные копии: как отслеживать удаление файлов - PullRequest
1 голос
/ 25 марта 2011

У меня есть решение для резервного копирования вне сайта, которое работает на C ++, чтобы разбивать файлы на блоки, и отслеживает блоки, используя хеши md5 в базе данных SQLITE3. И он передает блоки вместе с базой данных на удаленный сайт.

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

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

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

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

Ответы [ 3 ]

1 голос
/ 25 марта 2011

inotify с IN_DELETE?

0 голосов
/ 28 марта 2011

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

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

Например, пара таких таблиц может работать:

Path(text)    BackupIndex(int)
path/to/file1  1
path/to/file2  1
path/to/file1  2

Обратите внимание, что path/to/file2 не отображается в резервной копии # 2, поскольку она не была в каталоге во время резервного копирования (она должна быть удалена).

BackupIndex(int)    Timestamp(timestamp)
1                   2011-03-12 7:42:31 UTC
2                   2011-03-20 8:21:56 UTC

Кто-то хочет восстановить, поскольку файлы существовали 15 марта, вы посмотрите на таблицу индексов резервного копирования, увидите, что резервная копия №1 была самой последней, и посмотрите все пути, которые существовали в резервной копии 1, из таблицы путей.

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

0 голосов
/ 25 марта 2011

Создание службы для мониторинга каталога (используйте FindFirstChangeNotification или ReadDirectoryChangesW)

...