LINUX.ORG.RU

История изменений

Исправление znenyegvkby, (текущая версия) :

Скажем, пример для duply:

Без шифрования.

Не знаю, зачем, но хорошо, оправдаем какими-либо личными причинами:
GPG_KEY='disabled'

Без архивирования.

Не оправдывается ничем.

Суть в том чтобы автоматом при каждом новом бэкапе сохранял за последние 2 недели, а все что старше удалял.

MAX_FULLBKP_AGE=2W
--full-if-order-then $MAX_FULLBKP_AGE

Резервная полная копия шары делается каждую неделю

MAX_FULL_BACKUPS=2
Доп. настройка VOLSIZE-TARGET-SOURCE-etc от силы 5-10 минут. И запускаешь через крон с каким угодно интервалом (если без маразма, конечно). Плюсом получаешь инкременты и еще кучу полезностей (там выше уже писали, что саму логику создания - для большей гибкости лучше вынести в самописку). Я просто искренне не понимаю – если у тебя over9000Гб данных – зачем на каждый раз делать именно full backup? Это же огромные накладные расходы, если еще учитывать, что хранить бэкапы на том же носителе это маразм, и все равно их придется куда-то отправлять.

Исходная версия znenyegvkby, :

Скажем, пример для duply:

Без шифрования.

Не знаю, зачем, но хорошо, оправдаем каким-либо личными причинами
GPG_KEY='disabled'

Без архивирования.

Не оправдывается ничем.

Суть в том чтобы автоматом при каждом новом бэкапе сохранял за последние 2 недели, а все что старше удалял.

MAX_FULLBKP_AGE=2W
--full-if-order-then $MAX_FULLBKP_AGE

Резервная полная копия шары делается каждую неделю

MAX_FULL_BACKUPS=2
Доп. настройка VOLSIZE-TARGET-SOURCE-etc от силы 5-10 минут. И запускаешь через крон с каким угодно интервалом (если без маразма, конечно). Плюсом получаешь инкременты и еще кучу полезностей (там выше уже писали, что саму логику создания - для большей гибкости лучше вынести в самописку). Я просто искренне не понимаю – если у тебя over9000Гб данных – зачем на каждый раз делать именно full backup? Это же огромные накладные расходы, если еще учитывать, что хранить бэкапы на том же носителе это маразм, и все равно их придется куда-то отправлять.