Я работаю с несколькими клиентскими машинами OSX, которые выполняют резервное копирование черезМашина временив AFP-ресурсы на файловом сервере Ubuntu Linux, экспортированные netatalk/afpd. Эти клиенты выполняют резервное копирование в произвольное время дня, каждый день. На сервере также есть другие важные не-TimeMachine AFP-ресурсы.
На сервере резервные копии TimeMachine представлены в видеразреженные пучки- формат хранения данных, включающий множество «полос» - хранится в стандартной файловой системе EXT4. Внутри этого sparsebundle зарыт образ диска с файловой системой HFS+, которую использует TimeMachine, но со стороны сервера это просто набор файлов полос и некоторые метаданные верхнего уровня.
rsnapshotзапускается каждые 4 часа на сервере и создает резервные копии файлов и метаданных sparsebundle band на съемных носителях (для хранения вне сайта). Поэтому rsnapshot также создает резервные копии этих sparsebundle band в произвольное время дня. rsnapshot использует rsync для выполнения копирования.
Проблема в том, что если rsnapshot запускается, когда клиентская машина имеет смонтированный sparsebundle, я обеспокоен тем, что rsnapshot может захватить несогласованное состояние sparsebundle, поскольку полосы могут измениться в процессе резервного копирования. Очевидно, что это не способствует гарантированию восстанавливаемой резервной копии!
Я пытаюсь придумать способы обойти эту проблему. Кажется важным, чтобы sparsebundle не был смонтирован в то время, когда rsnapshot пытается сделать резервную копию. Со стороны сервера, единственный способ, который я вижу в настоящее время, это отключить демон aftp, возможно, дождавшись, пока sparsebundle будет размонтирован клиентом OSX. Недостатком этого является то, что он также переводит в автономный режим другие экспорты AFP, не относящиеся к TimeMachine, и это неприемлемо для пользователей. Насколько я могу судить, afpd не предоставляет способа (легко) добавлять или удалять экспорты - хотя одним из вариантов может быть некоторая автоматическая перезапись файлов конфигурации afpd для отключения экспорта TM во время резервного копирования rsnapshot, но это все равно отключает общие ресурсы AFP на короткое время.
Есть ли способ лучше?
решение1
Я бы не стал использовать Time Machine для группы компьютеров Mac. Слишком много проблем с разреженными пакетами и повреждением резервных копий.
Когда я столкнулся с похожей ситуацией, я выбрал CrashPlan, посчитав подход Time Machine непригодным для производства.
Стратегия резервного копирования для сред Apple, ориентированных на разработчиков?
решение2
Мысль.
Запустите снимок на самих устройствах Mac для фактического резервного копирования, резервные копии Time Machine будут дополнением.
ДА, гораздо лучше иметь образ Time Machine для восстановления, но иметь файлы с помощью rsnapshot — отличная идея.
Я использую смонтированные диски Amazon S3 с помощью Jungle Disk для хранения rsync или снимков образов.