Домашний сервер на Raspberry Pi B+, ч. 6; Бэкапы

[pechkin]

Спорить о необходимости и пользе бэкапов нужно с тем, кто их когда-нибудь искал. То есть, не нужно вообще. Вопрос стоит: как?

Что имеем:

• 300G фотографий


• 100G исходников музыки. Будет увеличиваться.


• 10G текстов, которые нужно сохранять.


• 10-20G музыки, которую нужно сохранять.


• 1G настроек, которые хочется иметь, чтобы быстро поднять. Здесь еще будет вопрос, какие это должны быть настройки и как их лучше собирать.


• 20G репозиториев SVN, о которых в предыдущем посте.

Имеем терабайтный диск, подключенный к серверу в кладовке. Диск монтируется непосредственно перед бэкапом и демонтируется сразу после (я думал, что это добавляет безопасности, но вдруг начал сомневаться). Имеем также 50G на Mega.nz, что-то еще на pCloud (эти обещали чуть ли не терабайт, но их хитрые раскосые глазенки не вызывают большого доверия). Можно наделать бесплатных аккаунтов, я думаю, сколько захочется. Есть 50G на гугле, но мне не нравится их соглашение, чтобы хранить там что-то слишком личное. Короче, что-то совсем ценное можно сбрасывать в разные облаки.

Схема мне видится пока такой:
1. rsync с сервера синхронизирует некий набор директорий на бэкапный терабайтник.
2. сервер архивирует содержимое бэкапа (с паролем)
3. этот архив заливается на облако, убирая предыдущий (потому что мне не нужные предыдущие состояния - все, где важна история, мониторится subversionом).

Джентльмены наверняка имеют свой собственный опыт в таких делах и могут пожелать вставить свой шестипенсовик - я открыт для ваших ценных замечаний.

Comments

[dmarck.livejournal.com]

если меняется малая часть данных (а, подозреваю, так оно и есть), получаем некислый оверхед на передаче.

тут спас бы просто rsync.

ну или отказаться от убирания предыдущего, а на втором шаге архивировать только файлы по (примерно) find -mtime -7d -or -ctime -7d

[pechkin.livejournal.com]

1. Оверхед на архивировании? Передачи происходят на первом и третьем шаге. И это меня не очень беспокоит, я за трафик не плачу. То есть, неприятно и может вылиться в ситуацию, когда бэкап по времени сопоставим с генерацией нового контента (если за день, скажем, не успеет все залить), но может ведь и успеть.

2. Здесь есть нюансы: часть бэкапируемого лежит на NTFSных разделах, там тоже будет работать mtime и ctime?

[dmarck.livejournal.com]

Оверхед на перезаливании каждый раз неизменившихся 400+ гигов. По-хорошему, full такого должен литься не чаще раза в квартал.

BTFS вроде бы поддерживает posix file attributes. Корректно ли они отдаются через механизмы монтирования -- надо проверять.

[pechkin.livejournal.com]

Вас понял, согласен.

[pechkin.livejournal.com]

Беда, наверно, в том, что я не могу делать rsync сразу на облако - они не монтируются как file system, или, по крайней мере, я не умею это делать.