Удаление старых бэкапов

по крону раз в неделю

Так удаляйте то, что старше N дней, не привязываясь к дате. Для поиска таких каталогов\файлов можно воспользоваться find с ключем mtime.

Ну и можно получать имя через date -d "2 week ago" или что-то подобное

Вот таким способом пробывал, не работает. find /mnt/archive/ -type d -mtime +14 -delete

У меня бэкапы делаются каждый день, нужно оставлять семь последних:

#!/bin/bash

cd /path/to/backups
ls -t | sed -e '1,7d' | xargs rm -rf

Вот таким способом пробывал, не работает. find /mnt/archive/ -type d -mtime +14 -delete

А почему плюс?
Файлы, измененные в процессе последних 4 дней:

$ find . -type f -mtime -4 -printf "%CY-%Cm-%Cd\t%f\n"
# Проверка:
$ find . -type f -mtime -4 -printf "%CY-%Cm-%Cd\n" | sort | uniq

Так удаляйте то, что старше N дней, не привязываясь к дате

Тогда отсутсвует контроль над тем случаем когда из-за бага оказалось что бекапы не делались. Такой код потрет последние бекапы

а ещё есть backup manager, который сам пакует, заливает куда надо и удаляет старое когда надо.

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

Так что что я хочу сказать. Если ты не хочешь юзать готовый софт для бекапов, то не ленись и пиши верификатор бекапов, который например после проверки бекапа на полноту будет писать файл вроде «backup_ready» и потом ты будешь в нормальном Python скрипте все эти файлы и удалять самые каталоги с этими файлами если остается не меньше 3х например. Не ленись

Рекомендую логику создания бекапов оставить в баше, а саму реализацию отдать на откуп duplicity.

Это у тебя такая задача разбитые на тома бэкапы готовить? С учетом full backup через определенные интервалы времени и инкрементальных для интервалов поменьше? С учетом шифрования и прочего? Если ты не курсовую пишешь (тогда man find/date) – то возьми уже какой-нибудь duply. На изучение конфигурации 20 минут – и про автоматизацию бэкапов можно забыть. А слать как тебе нужно и куда нужно, хоть в локальную директорию (хотя смысл бэкапа тогда теряется вообще, оО). Как там это говорится – шашешки или ехать?

Так если бэкапы не проверять то тогда вообще нет смысла их делать, так что тут вроде задача из другой плоскости.

А еще есть zfs, lvm, btrfs и nilfs2.

Нет не курсовая. Резервная полная копия шары делается каждую неделю.Без шифрования. Без архивирования. Суть в том чтобы автоматом при каждом новом бэкапе сохранял за последние 2 недели, а все что старше удалял. Просто уже устал в ручную удалять. А проморгаешь, память под забивку и все пиши пропало, шара падает((.

find $DIRECORY_TO_BACKUP -mtime +9 -delete

пихаем скрипт в cron.daily имеем десять ежедневных коипий

если непонятно могу скрипт кинуть, ну и всеж не каталог а архив будет

чего-то туплю cron.weekly и +20 тебе же недельный

Я решил развернуто обьяснить как делать бекапы, учитывая то, что автор хочет делать всякие дикие решения вроде удаления по TTL. На всякий случай

Это временный сервер с шарой, из-за чего не хочу тратить время чтобы писать верификатор бэкапов и так далее.

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

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

Это временный сервер с шарой, из-за чего не хочу тратить время чтобы писать верификатор бэкапов и так далее.

А писать этот бредовый скрипт, вместо того чтобы поставить ПО – минуту + 10-15 минут чтения документации (единоразово, ибо запоминается на раз два) ты хочешь? Странный подход.

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

Тебе уже помогли:
find /dir/ -mtime N(man) -delete
что конкретно из этой команды не понятно, ты скажи. Тебе уже несколько раз советовали.

MAX_AGE вернее, и MFA – 1W. Да не суть, доки просто прочти. А суть в том, что это время ты тратишь единоразово. А сколько сейчас ты уже потратил на эти велосипеды?

Бэкап на там же носителе на шаре имеет место быть. Это когда прибегают и говорят, «я тут файлик удалила, а можно его назад» ;) Для отдельных личностей по крону раз в пят минут синкается, хорошо хоть быстрей не работают. Самбовская корзина конечно хорошо, но осечки бывают, особенно когда файлы «новый документ №n»

Бэкап на там же носителе на шаре имеет место быть.

Изолированность – первое требование к _любому бэкапу_. В противном случае – это не бэкап. Это же касается версионности и целостности.

Это когда прибегают и говорят, «я тут файлик удалила, а можно его назад» ;)

Как это связано с физическим месторасположением файла? Правильно, никак. А в большинстве случаев – такие задачи решаются за счет адекватной архитектуры приложения. Если кто-то использует функционал приложения для изменения чего-угодно – и функционал _предусматривает_ вариант отката изменения – но по каким-либо причинам не реализован – ССЗБ. Даже если кто-то просто удаляет файл – для этого есть инкрементальные бэкапы определенных часто изменяемых директорий. Но и это не отменяет первые три правила бэкапа. Вообщем от задачи нужно отталкиваться.

ну мы же о целостности, версионностью там не пахнет. Глупо лазить на бэкап сервер, если нужна исключительно краткосрочная перспектива изменений, может и локально пожить. А то вдруг научаться не юзать шифтдел :)

Это временный сервер с шарой, из-за чего не хочу тратить время чтобы писать верификатор бэкапов и так далее.

Ну можете не собирать бэкапы тогда, реально. Потому что в тот самый момент как все сдохнет что вообще пипец окажется, что уже пол года ваша бэкапилка ловит ошибки с правами и вообще ничего не бэкапит.

Глупо лазить на бэкап сервер, если нужна исключительно краткосрочная перспектива изменений, может и локально пожить. А то вдруг научаться не юзать шифтдел :)

Но ведь это архитектурно решается. Зачем для такой задачи «лазить на бэкап сервер»? В linux достаточно ссылок. Пусть работают со ссылками прямо в директории. Удалил ссылку – демон потом почистил файлы, сохраняя при этом оригиналы в бэкапы при необходимости.

А если не в линукс, не ну там тоже можно извратиться. Есть одна проблема, они сами создают, таскают, пересылают файлы и вообще всячески над ними извращаются. И единственная возможность, это ограничить им пространство для маневра, усе. А дальше истерики, где мой файлик. С удовольствием посмотрю решение для разнородной сети.

А если не в линукс,

А что, такое волшебство как ссылки есть только в linux?

Есть одна проблема, они сами создают, таскают, пересылают файлы и вообще всячески над ними извращаются.

Ну ведь ССЗБ же, в чистом виде. Это как дать всем некомпетентным в компании root доступ к рабочим машинам и потом удивляться чему-то.

И единственная возможность, это ограничить им пространство для маневра, усе.

Нет, не единственное.

С удовольствием посмотрю решение для разнородной сети.

Будет четкое описание задачи – будет и четкий ответ. Для вариант «я тут файлик удалила, а можно его назад» достаточно будет пересмотреть метод работы с fs.

В офтопе есть жесткие.

Не ССЗБ, а работа у них такая, остальное некомпетентность местами, которая компенсируется другими качествами и знаниями. Увы это реалии.

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

предположим ты получил в файл или пайп список каталогов с бекапами, отсортированными по возрастанию:

2017-01-06
2017-01-13
2017-01-20
2017-01-27
2017-02-03
2017-02-10

| head -n -3 

выведет всё кроме последних трех.

| while read dir ; do 
   ...проверяешь что это каталоги с бекапами, а не корневой каталог, и удаляешь его rm -rf $dir ; 
done 

Тогда отсутсвует контроль над тем случаем когда из-за бага оказалось что бекапы не делались. Такой код потрет последние бекапы

И это можно «автоматизировать», если текущая проверка бэкапа не прошла, то делаем touch на предыдущий бэкап, у него становится время сегодняшее, а в имени - вчерашнее.

Спасибо за подсказки, переписал скрипт. Теперь все работает. Кому может понадобится код ниже

#!/bin/sh
#backup.sh
tar -czPf /mnt/archive/test/'BackUp - '`date '+%F'`.tar.gz  /mnt/Share_NAME/

Где: /mnt/archive/test/ -путь куда складываем
     'BackUp - '`date '+%F'`.tar.gz - имя,дата,формат
     /mnt/Share_NAME/ - что бэкапим

#Удаление бэкапов старше 14 дней
# Количество дней
day=13
# Путь до папки с файлами
where_find="/mnt/archive/backup_test"

find $where_find -name "*.tar.gz" -type f -mtime +$day -delete
#Сохранение логов
find $where_find -name "*.tar.gz" -type f -mtime +$day -delete > $where_find/log.txt
cat $where_find/log.txt

Плохой вариант. Вам выше написали уже Удаление старых бэкапов (комментарий) как минимум для вашего скрипта && добавить