Ребята, как вы решаете проблему с удалением бэкапов

В Oracle есть каталог и RMAN. МОжно задать retention window, скажем 14 дней. И есть команда, которая грамотно удаляет устаревшие бэкапы.

Пример:

F1 L1 L2 L3 D1 L4 L5 D2 L6 L7 L8 L9 F2 ...

Так вот, если D1 был сделан 15 дней назад, а F1 двадцать дней назад, то при retention window в 14 дней. RMAN не удалит F1, а только D1. Чтобы было в случае восстановления к чему применять D2 (к F1). Т. е. он не тупо косит бэкапы по дате, а рассматривает еще и что, собственно, бэкапилось. Так как одно может зависеть от другого.

Не нашел такого функционала в SQL Server'е. Как выкручиваетесь? Нашел OLga Halengren Scripts, там что-то реализовано с удалением, но не уверен, что она не делает как все (утпо по дате).

Заранее спасибо.

Зенит победит!,

А просто удалять раз в неделю все что старше двух недель, не?

offtop
это мне напомнило изобретение американцами ручки для космоса, тогда как наши просто писали там карандашами:)

WarAnt
Зенит победит!, А просто удалять раз в неделю все что старше двух недель, не? offtop это мне напомнило изобретение американцами ручки для космоса, тогда как наши просто писали там карандашами:)

не катит такая схема вы похерите такой схемой full'ы, а diff'ы и логи останутся висеть.. вы не внимательно читали пост. цимес в том что надо иметь возможность восстановления в окне - две последние недели.

Зенит победит!

WarAnt Зенит победит!, А просто удалять раз в неделю все что старше двух недель, не? offtop это мне напомнило изобретение американцами ручки для космоса, тогда как наши просто писали там карандашами:) не катит такая схема вы похерите такой схемой full'ы, а diff'ы и логи останутся висеть.. вы не внимательно читали пост. цимес в том что надо иметь возможность восстановления в окне - две последние недели.

не вижу большой проблемы в том, чтобы в процедуре/скрипте :
1) начитать список файлов из директории
2) для каждого файла выполнить restore headeronly и сохранить во времянку
3) проанализировать данные на основе даты создания бекапа и LSN-ы
4) собрать список файлов на удаление
5) удалить их

наверняка у кого-то такое решение уже есть

Зенит победит!
не катит такая схема вы похерите такой схемой full'ы, а diff'ы и логи останутся висеть.. вы не внимательно читали пост. цимес в том что надо иметь возможность восстановления в окне - две последние недели.

Обычно считается, что стоимость "правильного" удаления бакапов выше, чем стоимость хранения лишних файлов (то есть, в вашем случае, для восстановления на 2 недели нужно оставлять файлы полных бакапов за 2 недели + периодичность полных бакапов, то есть за 35 дней).

Если бизнесу это критично, если они посчитали баланс бабла, и он положительный, то можно написать скрипт, как пишет komrad
Наверняка такие уже есть, я вроде даже в форуме видел, можно поискать...
"Стандартное" решения из планов обслуживания удалает тупо по дате, это да.

Зенит победит!
не катит такая схема вы похерите такой схемой full'ы, а diff'ы и логи останутся висеть.

Откуда может взяться файл бэкапа, дата создания которого раньше даты содержащегося в нем бэкапа ?

Всем спасибо. О педалях я то знаю/понимаю как сделать. Просто после oracle это дикость, что это надо писать руками.

Glory
Зенит победит! не катит такая схема вы похерите такой схемой full'ы, а diff'ы и логи останутся висеть. Откуда может взяться файл бэкапа, дата создания которого раньше даты содержащегося в нем бэкапа ?

чего?

велосипеды изобретать весьма занятное дело, но по мне лучше иметь три каталога Full, Diff, LOG и соответственно настроить туда бэкапирование и чистику с нужной периодичностью для каждого.

Зенит победит!
Всем спасибо. О педалях я то знаю/понимаю как сделать. Просто после oracle это дикость, что это надо писать руками. Glory пропущено... Откуда может взяться файл бэкапа, дата создания которого раньше даты содержащегося в нем бэкапа ? чего?

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

Зенит победит!,

В планах обслуживания есть Maintenance Cleanup Task который чистит файлы бекапов в указанной директории по дате создания с учетом расширений. Ну и скриптами самописными, как уже говорили, можно всяких свистелок накрутить. Например проверку архивных атрибутов перед удалением.