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

мсье жеппится на диски?

Простая (Simple)
Бекап каждую ночь. Ощущения нормальные.

Полный + диф, ощущения сухости и комфорта.

Простая

Если с дисковым пространством проблемы то Фул + Инкрементальный каждые (сколько нужно) минут Иначе Фул + Диффер каждые (сколько нужно) минут.

full

(2) аналогично

(1) Да, покупали недавно сервер, от стоимости дисков я немного прозрел))

вариант как у (2), а ощущения как у (3)

full
Полные ночью и транзакций каждый час.
Правда, на бэкап-сервер раз в сутки копирование.
(8) Так тож серверные диски. Что тебе мешает бэкапить на обычные?

(10) Хз, есть иррациональное тревожное чувство

(11) Делай контрольные развертывания и спи спокойно.

(0) я simple поставил, до сих пор проблем не было...

(0) продуктовые - full, разработка и большинство тестов - simple.
Боязнь того, что не хватит дискового пространства слегка странная:
1. Если поставить 2008R2, то есть сжатие.
2. Больше 1-4 размеров базы резервных копий журналов транзакций в месяц даже на 2005-м редко бывает. А когда бывает - можно это легко предугадать.
3. Ну да, на бэкапы (все) нужно дискового пространства в 5-10 баз на 2005-м и в 1-3 на 2008R2. Но это ж обычные 7200 саташники (пусть даж и в raidе), чего там на спичках экономить?

Всем любителям симпла пламенный привет. И большое спасибо.

был simple т.к. время простоя было не критично вплоть до 24 часов

simple + full backup каждую ночь

Интересно - есть люди, которые откатывались на уровне транзакции при full ? :-)

(14) та не в жлобстве на дисковое пространство дело то...я просто не вижу смысла в full'е + это дополнительная нагрузка на дисковую подсистему, которая и так является самым узким местом сервера
(17) только хотел спросить...

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

Сие не эквивалентно разве полной модели?

симпл + еженочный бэкап.
(14) всем любителям фулл привет :) Не видел ни одного, кому бы удалось откатить на уровне транзакции при форс-мажоре)

(0)А что у Вас такого необычного с журналом транзакций? Копируйте его два раза в день с отсечкой - и не будет он давать Вам большого бэк-апа.

(17) Вопрос не столько в откатить на конкретную транзакцию, сколько в том, что при наличии полного бэкапа и РКЖТ можно восстановить на произвольное время, а при наличии полных и дифф - только на моменты бэкапа. Возможностью этой я пользовался неоднократно. Самое банальное - чтобы развернуть тестовую базу на момент "немного до нужного".
Ну и возможностью "на момент последнего бэкапа плюс tail" тоже приходилось пользоваться. Хотя всё-таки это уже экстрим.

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

(19) В этом "огрызке" информация только с момента самой ранней из сейчас открытых транзакций. Так что не вариант.

(20) Могу показать человек 10.

(21) А что значит "с отсечкой"?

(17) мы не откатывались... пару раз приходилось раскатывать копию на время до и после определенного события - смотреть что произошло

(17) +1000
поэтому Simple

(17)(18)(20) что значит "на уровне транзакции"? на момент времени предшествующий сбою из бэкапов журнала транзакций - приходилось успешно.
(19) нет, не получается. В полном бэкапе содержится тот минимум журнала транзакций, который необходим для приведения БД в согласованное состояние - т.е. там есть информация по незавершенным транзакциям (в момент окончания бэкапа) и по тем транзакциям, которые завершились, но данные ими измененные, еще не были записаны в файл данных. Почитайте про стадии recovery БД - roll back/roll forward.
Из полного (и диф) бэкапа можно восстановиться ТОЛЬКО на момент времени создания бэкапа. Использование предложения STOPAT при восстановлении полного/диф бэкапов не приводит к ошибке, но самим SQL Server'ом игнорируется.

(18) А какая дополнительная дисковая нагрузка?

(0) Ну и, конечно, бэкапы - последняя линия обороны. Если пришлось восстанавливать рабочую базу из бэкапа, значит уже есть ошибки в организации резервирования. Для баз от 50 пользователей выбить бюджет на тёплый зазеркаленный недосервер (хотя бы недосервер) не составляет большого труда. Зато позволяет гарантировать сокращение времени простоя до нескольких минут.

(0) "Боюсь на журнал транзакций и его бекапы у нас не хватит никаких дисков. "
Телепатирую - наверное сама база 5 гиг, а журнал 500 гиг? - отсюда такие страхи?
В курсе, что после первого бэкапа журнала, второй бэкап журнала будет мизерным?
Да и зачем использовать серверные диски...
Одно задание - раз в день полный бэкап, раз в полчаса - журнал.
На 2Тб диск за тритыщи рублей влезет год работы.

+(28) тем более журнал каждые сутки будет очищаться полным бэкапом.
Не думаю, что суммарно все разностные бэкапы за сутки займут больше нескольких гиг...

(22) Если использовать опцию TRUNCATE (точнее - не использовать NO_TRUNCATE) - журнал транзакций после копирования усекается.

(30) но это же и есть обычный режим. no_truncate нужен только в очень специальных случаях (бэкап лога с убитой базы и т.п.)

(26) ну раз в журнал транзакций пишется максимальное количество операций, то логично предположить, что это создает дополнительную нагрузку на диски + дополнительная фрагментация диска и прочие ништяки...

(25)Теперь вижу. Я получается как раз описал полную модель, когда каждый бекап содержит журнал транзакций с момента предыдущего бекапа

(32) Если файл транзакций остаётся одного размера (а не шринкуется/разрастается постоянно), то фрагментация минимальна. В симпле не пишется в лог только bulk-logged операции. А их в 1С мизерное количество (например, реструктуризация таблиц при изменении структуры). В остальном при симпле записывается в файл журнала всё то же самое, что и при фулл. А вот размер файла - да, небольшой, потому что при фулл хранится вся информация о транзакциях с момента предыдущего резервного копирования логов, а при симпле - с момента самой ранней открытой транзакции (а они вроде как обычно фиксируются или отменяются достаточно быстро).

Но!

До сих пор я жил с полной моделью и полными бекапами каждый день. Журнал не очищался и не поддавался сжатию

Вот сие:

EXECUTE master.dbo.xp_create_subdir N'D:\mssql_backup\KA'
GO
BACKUP DATABASE [KA] TO  DISK = N'D:\mssql_backup\KA\KA_backup_2012_04_27_165446_9869099.bak' WITH NOFORMAT, NOINIT,  NAME = N'KA_backup_2012_04_27_165446_9869099', SKIP, REWIND, NOUNLOAD, COMPRESSION,  STATS = 10

Бекапит ли оно журнал вообще, или для бекапа журнала нужно отдельный план обслуживания делать?

(35) бэкап лога это не трогает. никак.

(35) для "неразрастания" логов транзакций нужно применять регулярно BACKUP LOG

(30)Вы совершенно правы. Сначала меня удивил Ваш вопрос, и только сейчас я подумал, что МОЖЕТ БЫТЬ автор темы не бэкапирует журнал транзакций, так, как нужно (как Вы и указали). Тогда понятно, что ему никогда и никаких дисков не хватит независимо от модели восстановления БД.

(35)Сбэкапируйте журнал транзакций по-нормальному. Можете просто войти в Enterprise Manager и дать команду бекапировать только лог. И через некоторое время Вы увидите чудесное уменьшение Вашего журнала транзакций.