Я ищу способ сделать это эффективно, как с точки зрения дискового пространства, так и со многими большими разреженными файлами изображений Xen, такими как duplicity, bup, rsync, lvmsync womble и т. Д. ) и пропускной способности диска / сети. К сожалению, требования к пространству и полосе пропускания исключают инструменты, о которых я только что упомянул, поскольку они будут сканировать все содержимое файлов, чтобы найти разницы между источником и местом назначения.
Итак, я хочу избежать следующих подводных камней:
Слепое копирование целых файлов
Интенсивное сканирование файлов целиком для генерации контрольных сумм для сравнения
Избыточные копии данных на одном томе (из-за COW или другой функции) - и это должно сохраняться как для исходного, так и для целевого томов.
Значительное снижение производительности при нормальном использовании системы
Поиск привел меня к одному классному примеру, который соответствует всем вышеперечисленным критериям ... OS X Time Machine при использовании редкие пучки в качестве исходного тома. Да ладно, в Linux это не сработает. Но было интересно увидеть, как просто время выполнения отдельных «бэндов» файлов в разреженном пакете сообщает вам, какие биты были изменены с момента последней резервной копии - мгновенно и практически без усилий. Экономия места не идеальна, поскольку полосы имеют длину 4 МБ, но все же очень хорошо.
В конце концов, работая с логическими томами с тонким предоставлением, я наткнулся на набор тестов с тонким предоставлением, который включает пример использования данных о тонком распределении для быстрого дифференциального резервного копирования. Я думал, что нашел свое решение ... просто поместите изображения на тонкий LV и используйте снимки!
Но потом я понял, что это займет слишком много места на исходном томе, а также замедлит его. Нормальные LV предназначены для кратковременного использования.
Мне все еще нужно было задаться вопросом, есть ли какие-то скриптовые или хитрые параметры конфигурации, которые могут заставить логический том моментального снимка действовать как `` фантомный '' моментальный снимок: он будет записывать только данные о распределении блоков, связанные с измененными блоками, но не копировать на- записывать сами блоки данных. Этот фантомный снимок может быть прочитан сценарием резервного копирования и мгновенно выделить измененные блоки для данного LV. (Я предполагаю, что некоторые назовут это журналом.) Когда резервное копирование завершится успешно, он может удалить существующий фантомный снимок и создать новый для хранения информации об изменениях для следующей дифференциальной резервной копии.
Решение не обязательно должно включать LVM, но такой подход позволяет мне представить желаемое решение в более прочной форме. Должен быть какой-то способ достичь такого уровня эффективности резервного копирования в Linux.