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

ZFS и rsnapshot для резервного копирования

В настоящее время у меня есть сервер OwnCloud с примерно 25 учетными записями, 2,6 ТБ и умеренно растущим. Поскольку данные будут храниться в течение следующих нескольких десятилетий, данные OwnCloud хранятся в зеркальной файловой системе ZFS для сохранения целостности данных. Я использую rsnapshot для хранения ночных, еженедельных и ежемесячных снимков на диске 8 ТБ (файловая система ext), который периодически заменяется другим диском на 8 ТБ, хранящимся вне офиса.

Простота подключения диска 8 ТБ к любому Linux-компьютеру привлекательна для восстановления файлов или системы. Это хорошо работает уже 15 месяцев. Еще не требовалось восстанавливать из резервной копии, но 2 неисправных диска были заменены на ZFS.

Есть ли значительное преимущество в использовании снимков ZFS и / или использовании ZFS на резервных дисках для улучшения целостности файлов? Что было бы «передовой практикой», или моей нынешней системы должно хватить сейчас и в будущем?

ZFS send/recv "учитывает изменения": это означает, что при последующих резервных копиях передается только измененный блок. По сравнению с чем-то вроде rsnapshot, которому нужно ходить все метаданные, чтобы обнаружить любой потенциально измененный файл, а затем необходимо прочитать все измененные файлы для извлечения любых изменений, send/recv явно намного быстрее. Вместо того, чтобы изобретать велосипед, я предлагаю вам взглянуть на syncoid для планирования регулярного инкрементного резервного копирования.

Тем не менее, rsnapshot - замечательная программа, которую я активно использую, когда send/recv неприменимо (например, когда пункт назначения работает не на ZFS и / или мне нужно подключить его к системам, не поддерживающим ZFS).