На днях мы обсуждали про периодичность бекапов 1С баз вот тема:
У кого какая периодичность бекапа для больших и критичных баз?

Когда я поднял вопрос у своего ИТ начальника почему у нас не "полная" а "простая" модель восстановления?
Ответ (аргументы) был такой.
1. При полной  - логи растут очень быстро и всю память занимают.
2. Опытные админы  sql и и опытные 1С-ники ему советовали при больших база такой режим лучше.

Как я раньше озвучивал у меня базы одна 100 ГБ другая 250 ГБ. Есть еще куча разных баз на других серверах объемом меньше.
Все на разных серверах.

Какие у вас на этот счет мысли доводы и контраргументы?
Кстати в другой фирме другой мой ИТ начальник лет 10-15 назад твердил наоборот другое что не стоит делать простой.

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

И еще вопрос. Модель - "с неполным протоколированием" для 1С используется или нет?
Никогда не юзал этот режим.

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

+(3) Т.е. применительно к базам 1С преимуществ не знаю. В других случаях, когда, например, нужно зеркалировать БД, без полной модели не обойтись.

(4) Как и 99% всех случаев с 1С мне нужно лишь хранить базу на случай восстановления и для создании копий по необходимости.

(0) Про бэкапы есть хорошая статья от speshuric'а: http://infostart.ru/public/173494/
там всё расписано.
Всё зависит от конкретных условий, так что решать вам, как обычно :)

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

(7) Ну тут как посмотреть. Я просадок при диффе не замечал ни разу, но у нас конфигурация серверов заточена на быструю дисковую подсистему. С другой стороны, постоянное логирование тоже занимает ресурсы так или иначе. В таких условиях свободное место ценнее иллюзорных преимуществ, т.к. SSD не резиновые и слишком дороги, чтобы наращивать по каждому чиху :)

(6) Спасибо бегло прочитал.  Там в общем понятие про различные варианты бекапов. А вот пристальное глубокое сравнение  модели восстановления нет.
Просто пример, который и так всем известен.

(8) Логирование в любом случае занимает ресурсы сервера, при любой модели восстановления.
При full recovery скорее "административный" ресурс нагружается, т.к. надо постоянно следить за своевременным выполнением бэкапов и всяких регламентов. Но иногда это просто неизбежно.

(10) в симпл если административный ресурс прослакал - всё потеряно, лог провернулся, только новый полный. в фул просто вырос лог

Если делать бэкапы логов транзакций не растет сильно, а после его обслуживания у нас раз в месяц и вовсе маленьким становится.
А решать simple или full модель, исключительно от необходимости восстановления базы на конкретное время.
Для себя определяюсь так - полные копии и разностные делать только вне рабочего времени, далее если нужна возможность восстановится внутри рабочего времени то full и бэкапы логов, иначе simple.

(0) "логи растут очень быстро и всю память занимают." - если настроить всего 1 задание (бэкап лога), ничего никуда не растёт.

(13) Бакапы и периодичность бекапов ни как не влияет на размер лог файла.

(14) При полной модели влияют.

(0) Место на дисках сейчас дешевое. Аргумента в пользу простой модели вижу только два.

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

(0) Это на каких дисках место дешёвое? SSD терабайтный enterprise класса стоит за килобакс нередко, они обычно в рейде, что в случае с зеркалом удорожает место вдвое. А базы типа ERP растут как на дрожжах, за пару лет полтерабайта.

(17) Место дешевое на HDD, куда нормальные админы и делают бэкапы.

(14) BACKUP LOG (в отличие от BACKUP DATABASE) как раз позволяет удалить старые записи в логе.

(14) для логов достаточно использовать классику хдд, которая копеешная, запись в один поток за 300 мбс более чем
еще можно подумать что будет при обновлении базы в модели симпл, или просто при реструктуризации. будет оба на)

(20) Ничего страшного не будет, такие вот массовые изменения как раз таки в модели FULL не желательны.

(21) Да нет разницы при записи в базу при любом режиме. Только место под логи требуется.

(0) Ерунда какая-то.
Продуктивные базы должны быть всегда только в полной модели работать. И никак иначе.
Базы для разработки, тестирования или развёрнутые копии за прошлые (неактуальные) периоды - в зависимости от конкретных обстоятельств.

Аргументы про дисковое пространство звучат так же смешно, как использование SMS вместо WhatsApp или Telegram из-за дороговизны мобильного интернета.

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

(23) Отсутствие грамотных админов - очень веский аргумент :))

(0) Судя по прошлой ветке у тебя есть резервные копии с дискретностью в час. Зачем делать полную модель, если бизнес устраивает потеря данных за час работы? Если не устраивает, то лучше полную модель. Бэкапы замучаешься делать чаще.

(25) Так вот я хочу разобраться это идеальный вариант или что-то мы упустили.
Зачастую Бизнес и не знает что есть выбор. И вообще может и про бекапы не обсуждали досконально.
Или ИТ отдел поставил перед фактом что так и будет и все.
Бекапы не я же ручкам буду делать а сервер сам по расписанию...

Если можете с этим работать и данные важны чуть ли не последние 5 минут, то полная. Если не можете (логи там у вас растут, места не хватает, восстановить не получается) или данные за сутки не важны, то простая

(17) За пару лет там программистам тысяч 200 баксов заплатят. Что на этом фоне пара килобаксов?

Еще есть кому насыпать тут семечек?

Если достаточно раз в сутки то простая модель вполне сойдет

(0) Реорганизация\перестроение индексов на стороне SQL?
Перепишите на скрипт, он будет обслуживать только нужные таблицы, лог не будет разбухать после обслуживания, соответственно бэкапы тоже будут занимать меньше места.
Но если потребуется обработать большую таблицу, то он может резко вырасти, например:
1 день бэкап лога 10Гб
2 день бэкап лога 10Гб
3 день бэкап лога 70Гб

А при стандартной реорганизации\перестроении будет:
1 день бэкап лога 110Гб
2 день бэкап лога 110Гб
3 день бэкап лога 110Гб