Я пытаюсь обернуть голову rsync
поведение при использовании --link-dest
в качестве моей личной резервной копии.
Моя установка - Mac Pro с отдельным разделом данных, который я хочу сделать резервную копию на сервере ubuntu. Попытка сделать это с Time Machine пока не сработала (последняя проблема: неверный максимальный целевой размер 46 ГБ).
У меня все это работает с rsync
через ssh, и это меня устраивает.
Последнее, что я пробовал, - это создавать инкрементные резервные копии с помощью --link-dest
вариант. У меня по ssh работает (201_10_08 - полный бэкап)
rsync -avh --delete --link-dest=/mnt/backup_data/2014_10_08 /Volumes/Data/ user@host:/mnt/backup_data/2014_10_09
Это прекрасно работает с --link-dest
путь, указывающий на папку в целевой системе.
Теперь я попытался упростить это, определив backup_data
в качестве диска Samba и монтировать его с Mac (обновлен rsync до 3.0.9 на Mac из-за низкой производительности по сравнению с Samba старой версии).
Результат: Несмотря на одинаковую дату модификации, владелец и группа файлов на подключенном диске (что подтверждено stat
), последующие резервные копии создают полные резервные копии без жестких ссылок в целевой системе
Я попытался --link-dest=/mnt/backup_data/old
(результат: путь не может быть найден, что имеет смысл, поскольку доступ осуществляется только к smb, а не ко всей целевой системе), а также --link-dest=/Volume/mount/old
(с путем через smb mount на Mac, результат: без жестких ссылок, полное резервное копирование).
Я могу работать с решением, которое разработал, но мне хотелось бы понять его поведение.
Есть идеи?
IIRC версия rsync, поставляемая с OS X, не является самой последней, и вы можете столкнуться со следующей проблемой:
Обратите внимание, что в версиях rsync до 2.6.1 была ошибка, которая могла предотвратить
--link-dest
от правильной работы для не суперпользователя, когда-o
было указано (или подразумевается-a
). Вы можете обойти эту ошибку, избегая-o
опция при отправке в старый rsync.