Назад | Перейти на главную страницу

Rsync --link-dest экономия места

Я пытаюсь использовать rsync и «--link-dest =» для создания инкрементных копий резервных копий на сервере (Debian Wheezy, LVM, RAID 1) с целью использования жестких ссылок для экономии места.

В отличие от «обычного» варианта использования, я хочу выполнять резервное копирование каждый день с клиента Windows в папку на сервере с именем «1» (эта часть работает, хотя я не использую здесь rsync для резервного копирования) , а затем отключение rsync от «1» для создания дополнительных изменений на 30 дней. Таким образом, «1» меняется с каждым днем ​​резервного копирования от клиента, но сделанные с него копии будут содержать более старые версии файлов за 30 дней.

Из сообщения на http://blog.interlinked.org/tutorials/rsync_time_machine.html в котором описывается, как использовать rsync для имитации того, что делает Apple Time Machine, у меня есть следующий код (часть целевого пути «15/16» представляет день / время резервного копирования):

    date=`date "+%Y-%m-%dT%H:%M:%S"`
    $UserNameVar=client8

    rsync -aP --log-file=/home/User1/Desktop/rsync.log  --link-dest=/home/$UserNameVar/share/Backups/1/current /home/$UserNameVar/share/Backups/1 /home/$UserNameVar/share/Backups/15/16/back-$date

    rm -f /home/$UserNameVar/share/Backups/1/current
    ln -s back-$date /home/$UserNameVar/share/Backups/1/current

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

Ошибочен ли подход или что-то в моем коде не так? Или мне нужен другой способ расчета фактического свободного места?

Спасибо

Есть несколько способов определить, --link-dest работает так, как вы ожидаете.

Один из способов - использовать команду find для поиска файлы с количеством жестких ссылок больше 1. Что-то вроде find . -type f -links +1.

В du Команда также обычно подсчитывает только один файл один раз, даже если на него много жестких ссылок.

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

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

Кстати, я большой поклонник использования грязный вместо того, чтобы пытаться накрутить собственный скрипт. Это в основном инструмент, который запускает rsync в режиме link-dest.

Вы смотрели на rdiff-резервное копирование?

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

rdiff-backup выполняет резервное копирование одного каталога в другой, возможно, по сети. Целевой каталог является копией исходного каталога, но дополнительные обратные различия хранятся в специальном подкаталоге этого целевого каталога, поэтому вы все равно можете восстановить файлы, потерянные некоторое время назад. Идея состоит в том, чтобы объединить лучшие функции зеркала и инкрементного резервного копирования. rdiff-backup также сохраняет подкаталоги, жесткие ссылки, файлы dev, разрешения, владение uid / gid, время модификации, расширенные атрибуты, списки контроля доступа и вилки ресурсов. Кроме того, rdiff-backup может работать с эффективным использованием полосы пропускания по каналу, как rsync. Таким образом, вы можете использовать rdiff-backup и ssh для безопасного резервного копирования жесткого диска в удаленное место, и будут передаваться только различия. Наконец, rdiff-backup прост в использовании, а настройки имеют разумные значения по умолчанию.

Я широко использую его для резервного копирования серверов в сочетании с backupninja.

Мне повезло с Backup.rsync - он даже смог сделать резервную копию хоста с нестабильным сетевым драйвером, где tar не работал. Он хранит несколько повторяющихся файлов и не сжимает их, но работает быстро.

Он хранит произвольное количество резервных копий и прекрасно возобновит предыдущее прерванное резервное копирование.

Это действительно просто обертка вокруг rsync --link-dest с некоторым mv'ing.