С недавних пор начали использовать MSSQL2016 сервер, под 1С, правда, есть еще нерешенные вопросы связаны с производительностью, но сейчас не об этом.
Начал учить MSSQL, а точнее приобрел видеокурс один, там как раз про 1С + MSSQL.
Там говорится, что надо делать регламентные задачи, а именно вот по такой блок-схеме:
Создаем план обслуживание, настраиваем на выполнение ежедневно > Потом из план элементов тащим объекты и настраиваем вот так:

Проверка целостности БД (выбираем пользовательские БД) >(успешное завершение) > Перестроение индексов (выбор БД) > (завершение) > Обновление статистики (выбор ДБ) > (завершение) > Выполнение инструкции T-SQL (DBCC FREEPROCCACHE) > (завершение) > Резервное копирование БД (выбираем БД, ставим время, место хранения) > (завершение) > Резервное копирование БД (делаем тоже самое, но для хранения в другом сервере) > (завершение) > Очистка журнала (ставим 1 неделю) > (завершение) > Очистка после обслуживание (7 дней, удалить на основе возраста во время выполнения задачи, выбираем папку где хранятся бекапы)

Теперь хотел бы у вас спросить - на сколько ли эта схема годная? что то добавить/удалить оттуда надо? Ну или изменить.

У нас 7 пользовательских БД 1С, суммарно, с логами базы весят 30ГБ, самая большая база весит 15ГБ.
Схема восстановления у нас - простая.

P.S. Кто не знает, то скажу, что после переезда из файловой версии на SQL, появились тормоза. на файловом версии работали под RDP.

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

Перенесите, пожалуйста, обратно в тему MSSQL, тема все же про SQL, а не про 1С !
Тут вряд ли кто то ответит.

Вот общая схема, проверьте пожалуйста:
http://images.vfl.ru/ii/1500286677/750e8c90/17949033.jpg

модель восстановления у нас простое.

авторРезервное копирование БД (делаем тоже самое, но для хранения в другом сервере)
Глупость. Резервная копия копии делается копированием. Любую из копий желательно проверить восстановлением.

Этот пункт исключил пока что.
А проверить пока не знаю как.. на боевом сервере боюсь поэкспериментировать. У меня есть тестовый сервер w2k16, под Hyper-V.
Посоветовали там поставить MSSQL 2016 developer версию и там делать эксперименты.
Но а как тестировать БД? мне надо будет там поднять 1С сервер еще, подключится платформой и проверить в 1С все записи? ну или можно без 1С сервера обойтись ?

авторМожете писать все архивы в 1 файл, с указанием срока жизни архива. На практике зависит от требований бизнеса по хранению архивов (для торговли обычно актуальна последняя рабочая версия, для бухгалтеров ещё и закрытые периоды).
да, у нас торговля. получается 1 база торговли, и 6 штук других баз (зуп, бухгалтерия). Все пишу в отдельности (полный бекап) и храню 7 дней.
Насчет квартальных БД не знаю. мне лично не сказали хранить, но уверен, если спросить бухгалтеров, они скажут храни все, до конца жизни )))) По этому тоже 7 дней храню и все.

AHDP , спасибо за разъяснение.

авторДля проверки бэкапа - достаточно развернуть в SQL сервере.
То есть если просто удачно восстановлю db.bak файл на другом SQL сервере, то можно считать бекап годным?

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

План вот готов, хотел бы запустить, проверить всели работает.. но знаю, что будет все тормозить. Вот хочу всем сказать, чтоб вышли из 1С на какое то время, чтоб запустить эту задачу.
Могли бы сказать насколько этот процесс долгий? ну хотябы приблизительно.
32Гб ОЗУ, диски SSD. суммарная база с журналами - 30ГБ.

Сисой,
Запустил все же задачу. думал на 5-10мин, но уже 40 мин прошел, но не закончился еще. пришлось пользователей пустить работать.
можно ли посмотреть ход операции? посмотреть на каком этапе? а то только показывает, что выполняется, и все.

авторХраним бэкапы (сжатые, естественно) за 2 недели - каждый день - диск+лента; последние 6 месяцев - 2 раза в месяц, последние 3 года - на каждую дату закрытия отчетных периодов (как правило, 15-20 число следующего месяца) - лента.
да, я поговорил с руководством, говорят, что надо хранить пол года, чтоб можно было откатить в любую дату. Но на сервере не смогу все это хранить, т.к. дики у меня SSD и не хочу забить их бекапами.
есть у нас резервный сервер, на HDD дисках. Я там хочу ставить FreeNas(или NAS4Free) и там хранить данные. Но как можно автоматизировать этот процесс?

авторБэкапы не делают на SSD. Как правило.

делается на SSD(локально), но потом их хочу перекинуть на HDD, на другой сервер.

автор Если нет места для копии - выгнать главного по ИТ за профнепригодность.
))))))) :D я вас умоляю! кого выгнать? директору? И так кое как добились 4 дисков, чтоб делать RAID, иначе сказал зачем 4, купите 2 и все. Это вам не какой то банк или международная контора, где все по стандарту и регламенту.
А чем SSD хуже то?

P.S. Кстати, перестраивание индексов , он и есть дифрагментация? это не навредит SSD диски?

AHDP,

У нас RAID1, на первом OS, на втором БД.
Теперь как быть тогда с перестроением индексами ? Не делать или делать не каждый день ?

закончились регламентные задачи. все выполнилась без ошибок.
Но есть одно замечание - ОЗУ не "отпускает", как загрузил до максимуму, так и остался.
У нас выделен 16ГБ под MSSQL, он полностью сейчас забит. (77% от общего)
А до регламентных задач он забивался до 65%

автор- Но основную нагрузку на первом даёт файл подкачки? При наличии двух массивов хранить на одном файл данных и лог БД не лучшее решение.

Тут я с вами не соглашусь, ибо столько людей, столько мнений.

автор- Зависит от ваших данных. Не знаешь - делай каждый день.
После выполнения этих задач единственным плюсом стал уменшение баз, из 15ГБ базы ушло около 50-60МБ. мелочь, но приятно )))
хотя тормоза остались. Но наверно запущу неделю один раз. бекапы каждый день.

авторP.S. А серверу 1С осталось 3 Гб?
Вот смотрите что творится:
http://images.vfl.ru/ii/1500360999/aa3a9231/17957450.jpg
http://images.vfl.ru/ii/1500361021/1c149305/17957453.jpg
sqlrun - это специальная учетка, под которого работает SQL, чтоб не был зависим от наших учетных записей.
скрытые - это RDP сеанс админа

Еще 4ГБ выделил под hyper-V одному серверу.