В настоящее время я разрабатываю систему резервного копирования Xen, однако я столкнулся со следующей проблемой:
У меня есть два метода резервного копирования:
dd из снимка LVM и tarпозвонить и удаленно выполнить синхронизациюТеперь второй вариант позволяет мне использовать rdiff-backupпоэтому я могу сохранять инкрементные резервные копии и экономить много места, в то время как первый вариант действительно занимает много места.
Теперь у меня два вопроса:
dd? Скажем, у меня есть LVM-том 50 ГБ, и при использовании используется только 3 ГБ dd он создаст образ размером 50 ГБ (и 47 ГБ будет потрачено впустую). tar может это исправить, но требует много дополнительного времени (которого у меня в основном нет)img файлы, созданные dd сохраняется каким-то образом постепенно?Вернемся к основам из вашего снимка. Во-первых, я попрошу вас понять, почему вы архивируете один файл. Остановитесь и подумайте немного о том, что делает tar и почему вы это делаете.
$ dd if=/dev/zero of=zero bs=$((1024*1024)) count=2048
2048+0 records in
2048+0 records out
2147483648 bytes transferred in 46.748718 secs (45936739 bytes/sec)
$ time gzip zero
real 1m0.333s
user 0m37.838s
sys 0m1.778s
$ ls -l zero.gz
-rw-r--r-- 1 user group 2084110 Mar 11 16:18 zero.gz
Учитывая это, мы видим, что сжатие дает нам преимущество около 1000: 1 по сравнению с пустым пространством. Сжатие работает независимо от поддержки разреженных файлов системой. Есть и другие алгоритмы, которые еще больше усложнят его, но для чистой общей производительности gzip побеждает.
Учитывая систему с поддержкой разреженных файлов, dd иногда есть возможность сэкономить место. Любопытно, что мой Mac включает в себя версию dd который имеет conv=sparse флаг, но файловая система HFS + не поддерживает его. Напротив, свежая установка Debian, которую я использовал для тестирования, поддерживает разреженные файлы в ext4, но эта установка dd нет флага. Иди разберись.
Итак, еще одно упражнение:
Я скопировал / dev / zero в файл так же, как указано выше. Он занимал 2 ГБ места в файловой системе, что подтверждается du, df, и ls. Затем я использовал cp на нем и обнаружил, что у меня 2 файла, занимающие 4 ГБ места. Итак, пора попробовать другой флаг:
`cp --sparse=always sparse sparse2`
Это заставляет cp брать обычный файл и использовать разреженное распределение всякий раз, когда он видит длинную строку нулей. Теперь у меня есть 2 файла, которые занимают 4 ГБ в соответствии с ls, но только 2 ГБ согласно du и df.
Теперь, когда у меня есть разреженный файл, будет ли вести себя cp? Да. cp sparse2 sparse приводит к тому, что ls покажите мне 2 ГБ занятого пространства для каждого файла, но du показывает, что они занимают нулевые блоки в файловой системе. Вывод: некоторые утилиты будут уважать и без того разреженный файл, но большинство будут записывать все обратно. Четный cp не знает, как превратить записанный файл обратно в разреженный, если вы не заставите его попробовать.
Затем я создал файл размером 1 МБ и сделал его разреженной записью, а затем попытался отредактировать его в vim. Несмотря на то, что мы вводим всего несколько символов, мы снова используем все. Быстрый поиск нашел похожую демонстрацию: https://unix.stackexchange.com/questions/17572/what-is-the-interaction-of-the-rsync-size-only-and-sparse-options
Итак, мои мысли, учитывая все это:
rsync -S копировать с разреженными файлами в результатеcp --sparse=always против нерасширенного изображения, чтобы создать разреженную копию.Обратной стороной проблемы дифференциального резервного копирования на блочных устройствах является то, что все может немного перемещаться и создавать большие громоздкие различия. Есть обсуждение StackOverflow: https://stackoverflow.com/questions/4731035/binary-diff-and-patch-utility-for-a-virtual-machine-image что пришло к выводу, что лучше всего использовать xdelta. Если вы собираетесь это сделать, снова попробуйте сначала обнулить ваше пустое пространство.
Ваши два вопроса ...
dd просто принимает секторы как образ. Невозможно указать ему пропускать пустые места; он создаст точный образ диска, который вы копируете. Однако, если вы перенаправляете вывод с помощью утилиты сжатия, такой как zip или 7z, пробелы должны сжать его для почти такого же эффекта. Это все равно займет время (поскольку утилита dd все еще дублирует пустое пространство), но фактор размера хранилища будет значительно уменьшен; У меня есть образ диска размером 100+ гигабайт от VMWare, который сжимается примерно до 20 гигабайт из-за неиспользуемого пространства.
Что касается постепенного сохранения, насколько мне известно. Откуда мне знать, что изменилось, а что нет? На самом деле это не предназначалось. Инкрементные сохранения, скорее всего, придется выполнять с помощью таких утилит, как rdiff-backup или rsync, и сжимать их, делая это на уровне файлов.
tar не может исправить потраченное впустую пространство, если оно не заполнено нулями (обычно это не так). Запуск инструмента для обнуления свободного пространства, как предлагал Джефф, приведет к тому, что моментальный снимок будет собирать большие объемы данных, что займет много времени и израсходует много места для резервного хранилища моментальных снимков. Есть ли причина, по которой вы не хотите монтировать снимок и rsync или rdiff-backup который? Вы также можете посмотреть dump который может быстро создавать резервные копии снимка без монтирования (если это ext [234]) и выполнять многоуровневое инкрементное резервное копирование. Это может быть намного быстрее, чем tar или rsync для файловых систем с большим количеством небольших файлов. Он также может выполнять многопоточное сжатие.