8.х Бэкап 1С

1. Да, правильно. Создается полная копия.
Лучше делать это не вручную, а засунуть в планы обслуживания Management Studio, чтобы само архивировалось в нужное время.
Следует иметь в виду, что при каком либо сбое сервера Вы этот бэкап можете развернуть ТОЛЬКО на SQL сервере. Поэтому более универсальным будет бэкап средствами 1С в файл с расширением dt.
Этот бэкап Вы сможете загрузить как в скуль, так и в файловую базу (кстати такое может делать не только 1С, но и сторонние архиваторы по расписанию). Но при таком бэкапе надо выгнать всех пользователей из базы (при бэкапе средствами SQL это делать не обязательно).


2. Если в Моих Документах имеется в виду файл 1Cv8.1CD, то тоже правильно.
Перед бэкапом обязательно выгнать из базы всех пользователей.

Он один там файл - 1Cv8.1CD

По поводу правильности и надёжности есть пара отступлений...
1) Обязательно делайте ротацию бэкапов(например за неделю)
2) Бэкапы в SQL бывают разные... Есть полный, разностный и тд... Есть журнал транзакций... Это то же необходимо всё правильно настроить и вовремя очищать, а иначе это съест свободное место на диске.
3) делайте копию бэкапа на другой носитель.
Так же ещё надо правильно настроить регламентные задания: перестроения индексов, тестирование БД и тд....

Вы предлагаете перенести в виртуалку только 1С сервер или SQL тоже?
И Снапшоты делать целой виртуалки?

Назовите, пожалуйста, положительные стороны такого решения.

[off]ИМХО, делать такое на боевом нагруженном сервере - редкостный изврат. :angry:
Для изучения, тестирования, или как временное решение - может быть еще... [/off]

Для того что бы установить обновления нужен монопольный захват базы, то есть выгонять пользователей по любому... А за использование "Динамического обновления" можно и по шапке получить....

В типовых конфах есть обработка которая блокирует соединения с БД. Там всё предельно просто устанавливаете время, обработка оповещает пользователей что бы они закончили текущие дела и вышли из БД. Ну а далее обновляете.
То есть вы выгоняете юзеров, делаете бэкап, потом обновляете и готово...

З.Ы. По хорошему ещё бы не плохо бэкап проверять на работоспособность. То есть делать тестовое восстановление. Особенно если дело касается *.dt и если база лежит на одном винте(в смысле нет RAIDа).

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

И правильно говорят, что динамическое обновление - зло. :angry:

Я обычно делаю в dt. То есть у меня настроены в sql бэкапы и делаются автоматически. А при обновлении выгружаю dt.