Поискал на формумах,но полной информации по специфике стратегии
backup для SAP и MS SQL не накопал.
Интересует такой вопрос:
Имеем ERP 2005 SR1, MS SQL 2005 64 bit
Начальный размер базы данных около 60 ГБ.
Система на 40 пользователей, загруженность предполагается не очень высокой, бакап ведется на дисковый массив.
Думаю настроить такой план db13:
1. Full Backup - 2 раза в неделю ночью , к примеру в 03-00
2. Transaction Log backup - 1-2 раза в день , например в 11-00 и 16 -00 часов, учитывая транзакционную активность пользователей системы (с 9 до 10 утра пока чай ,кофе и т.п )
3. Diff Backup - ежедневно вечером или ночью
Подходит такой план backup MS SQL? Не будет ли расти transaction log - сейчас он 11 GB!
И еще вопрос по db13:
С учетом backup на диск какие параметры инициировать для перезаписи файлов бакапа? Для теста ставил expiration date в 0б галочку init tape, но не перезаписывается файл. Надо еще format галочку включать? По ms sql опыта нет, пока у клиента не примут спеца по SQl server, надо накидать план по backup...

галочка init - off, format - on - нормально перезаписывается!
осталось определиться с последовательностью действий,
после полного бакапа советуют на форумах sql.ru делать transaction log backup, затем дифф бакапы для больших баз...

Я обычно использую для продуктива схему такую:
1. Раз в неделю - полный (full) бэкап
2. Раз в день - diff
3. Раз в 1-2 часа - бэкап логов.

Это близко к рекомендациям САП из курса ADM520 (точнее, это один из рекомендованных вариантов). Можно вместо диффов делать каждый день полные бэкапы, но это увеличивает объем, необходимый для хранения бэкапов (впрочем, старые бэкапы для хранения на диске можно архивировать - жмутся они хорошо).

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

Скорость роста лога зависит от интенсивности работы в системе. Лог в 11 Гб кажется мне слишком большим. Стоит его подобрезать.

Еще одно. Мне кажется неудобным саповский планировщик бэкапов. Предпочитаю планировать через интерфейс СУБД (SQL Server Management Studio, если говорить про 2005й MS SQL).

Спасибо!
по поводу shrinka для transaction log - в какой момент можно выполнять обрезание размера лога транзакций?
В любой момент или обязательно после какого-либо из бакапов (full,diff или transaction log backup)?
И каковы рекомендации по поддержанию оптималного размера лога транзакций для больших баз SAP?

по ссылке http://www.sql.ru/forum/actualthread.as ... log+backup
говорится что "... если сделать бэкапы базы и лога, то шринк работает." - это в стандартных средствах MS SQL работает?
из db13 проводил full, diff, transaction log backup - размер лога не уменьшился, и опций нигде не спрашивается насчет усечения размера лога...

Шринк (то есть уменьшение физического размера) файла лога можно делать тогда, когда в нем есть свободное место. Поэтому, конечно, правильнее проводить его после бэкапа лога.
Рекомендация простая - надо чаще делать бэкап логов, тогда лог-файл не будет успевать вырасти (поскольку при бэкапе логов место, занятое тем его содержимым, что записано в бэкап, помечается как свободное).