История изменений
Исправление 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? Это же огромные накладные расходы, если еще учитывать, что хранить бэкапы на том же носителе это маразм, и все равно их придется куда-то отправлять.