Запись файловой системы пишет как бинарный diff для удаленного приложения?

Question

Я работаю с постоянно обновляемыми резервными копиями Interbase размером ~ 20 ГБ, которые я хочу скопировать через Интернет. Как я могу минимизировать объем передаваемых данных?

Я подумывал об использовании бинарного средства сравнения, но я понимаю, что bsdiff требует как минимум O (7n) памяти, и эти резервные копии Interbase меняются только постепенно по локальной сети, используя в любом случае проприетарную вещь gbak Interbase. Можно ли каким-то образом подключиться к файловой системе linux (ext / btrfs / ...), чтобы зафиксировать все изменения, внесенные в этот файл, экспортировать их в общий формат diff и собрать их на другой платформе (windows)?

Answer 1

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

Это даст вам очень мало данных для резервного копирования.

Answer 2

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

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

есть такие инструменты, как xdelta, которые могут помочь в этом случае, поскольку они используют оконный подход к дельта-вычислениям и могут найти общие части, намного меньшие, чем rsync, и, таким образом, сохранить общую часть, хотя наличие более высокой плотности изменений. вам понадобится «старая» и последняя резервная копия, чтобы использовать это.

Хорошая новость заключается в том, что резервное копирование, вероятно, будет организовываться одинаково при каждом выполнении (одинаковый порядок таблиц / строк), и это поможет обоим алгоритмам.