LINUX.ORG.RU
решено ФорумAdmin

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

 , ,


1

1

Добрый день. Нужна помощь, так как не очень силен в bash. Написал небольшой скрипт для бэкапа. Бэкапит в каталогис именем 2017-01-27 по крону раз в неделю. Не могу разобраться как дописать скрипт чтобы, каждый раз при бэкапе сохранял 2 каталога предыдущих бекапов и удалял старые.

  • Например есть каталоги:
  • 2017-01-20 - чтобы удалился как только будет сделан бэкап 10 числа
  • 2017-01-27 - сохранить(чтобы остался)
  • 2017-02-03 - сохранить(чтобы остался)
  • 2017-02-10 - 10 числа будет сделан новый бэкап
    • #!/bin/sh
    • mkdir -p «/mnt/archive/'date +%F'»
    • rsync -a /mnt/Share_NAME /mnt/archive/'date +%F'
    • date
    • echo «'date' - Share_NAME backup»>>archive.log


Последнее исправление: goladranec (всего исправлений: 3)
Ответ на: комментарий от goladranec

Скажем, пример для 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
()
Последнее исправление: znenyegvkby (всего исправлений: 1)
Ответ на: комментарий от znenyegvkby

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

znenyegvkby
()
Ответ на: комментарий от znenyegvkby

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

Morin ★★★★★
()
Ответ на: комментарий от Morin

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

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

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

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

znenyegvkby
()
Ответ на: комментарий от znenyegvkby

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

Morin ★★★★★
()
Ответ на: комментарий от Morin

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

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

znenyegvkby
()
Последнее исправление: znenyegvkby (всего исправлений: 1)
Ответ на: комментарий от znenyegvkby

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

Morin ★★★★★
()
Ответ на: комментарий от Morin

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

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

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

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

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

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

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

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

znenyegvkby
()
Последнее исправление: znenyegvkby (всего исправлений: 1)
Ответ на: комментарий от znenyegvkby

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

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

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

Morin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.