Всем привет!
1С:Предприятие 8.2 стоит на сервере удаленных рабочих столов (Windows Server 2012), файловые базы лежат на сетевой шаре файлового сервера (тоже Windows Server 2012). Пользователи свои сеансы не закрывают, соответственно 1С тоже.
Имеется ли официальная информация о корректности применения штатной функциональности ОС Windows Server 2012 - Система архивации Windows Server для архивирования файловых баз 1С на общем сетевом ресурсе?
Теоритически "Система архивации Windows Server" работает с применением VSS (Volume Shadow Copy Service), которая должна обеспечить корректность архивирования файла "1Сv8.1CD" или база 1С имеет определенную специфику и применение теневых копий в процессе архивирования не гарантирует 100% создания успешной резервной копии?
Я так понимаю клиентская часть 1С должна уметь работать с VSS, завершить файловый ввод-вывод по запросу службы VSS и т.д., а вот умеет ли не понятно???

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

в плане проверки это понятно... с другой стороны в этом вопросе тыкать пальцем в небо как-то не хочется, неужели нигде нет официальной информации от разработчиков 1с о применимости Windows Backup для архивирования баз *.1cd

(2) Сейчас разработчики 1С всё бросят, и начнут тестировать "Систему архивации Windows Server"

Каждую ночь бэкапь, этого достаточно будет

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

скорее всего работа с файловым механизмом не развивается.
и в нем остались ошибки 1с8.1 , которые делают поврежденными
копии файла 1Cv8.1CD, если есть открытые сессии.

Если будете экспериментировать, отпишитесь о условиях эксперимента и результатах.

(5) если вместе с файлом 1cd все временные файлы скопировать, то повреждения базы не происходит.

(4) так разберись и здесь расскажи, возможно есть еще прецеденты с файловыми базами с незакрывающимися сеансами :)

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

(4) Разработчики 1С предоставили всю исчерпывающую информацию по созданиям резервных копий в "Руководстве администратора", там специально выделено отдельным пунктом:
ВНИМАНИЕ! Для обеспечения целостности и согласованности данных работа пользователей с ИБ во время создания резервной копии должна быть запрещена.
Так что никакого специального механизма для взаимодействия с VSSS в программе нету, да и если честно я не представляю, как клиентские экземпляры 1С, запущенные на рабочих станциях, смогут что-то сообщить на VSSS, который запущен на сервере где лежит 1Cv8.1CD

(0) >Я так понимаю клиентская часть 1С должна уметь работать с VSS, завершить файловый ввод-вывод по запросу службы VSS и т.д., а вот умеет ли не понятно???

Если немного подумать, то становится очевидно, что в файловом варианте 1С этого сделать не в состоянии. С файлом базы работают процессы, находящиеся на клиентских машинах. Они просто не способны взаимодействовать с VSS, работающей на сервере. Сервер 1С теоретически мог бы это делать, но он работает только с базой SQL, которая сама взаимодействует с VSS либо имеет свои средства для бэкапа.

Остается еще вариант работы с файловой базой по HTTP через модуль расширения веб-сервера. О нем можно спросить поддержку 1С. Я уверен, что ответ будет "даже и не думали заморачиваться".

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

(10) Что касается остановки процесса записи по запросу системы резервного копирования - то запись-то остановится, тем более, что останов будет на уровне сетевого протокола - процессы просто "подвиснут", пока идёт копирование и сформируется теневая копия. Только сами процессы 1С не узнают, что их кто-то останавливал, и продолжат запись дальше.

И, мне кажется, что в случае выделения памяти под таблицу в файле 1С мы можем даже поймать состояние, когда память выделена, но в заголовке ещё не записана.

Единственное, что может спасти от "тяжёлых последствий" - это выставляемые 1С блокировки участков файла - если какой-то участок файла заблокирован, то средство резервного копирования не получит доступа к такому файлу, пока не будет снята блокировка, что теоретически должно исключать ситуацию в (12).

вот тут http://technet.microsoft.com/ru-ru/library/ee923636(v=ws.10).aspx описано как работает служба теневого копирования и ее взаимодействие с системой резервного копирования...
Исходя из написанного встроенная в ОС "система резервного копирования" использует VSS в процессе работы, которая состоит из нескольких компонентов (VSS service, VSS requester, VSS writer, VSS provider), задача которых решить все проблемы, о которых говорится в  постах 5, 9, 10, 11, 12, 13. Что касается работы VSS по сети (точнее по SMB протоколу): запросы компонентов службы транслируются в сеть, иначе бы не работало теневое копирование для общих папок (сетевых шар), которое использует ту же службу VSS для создания полной теневой копии тома, на котором расположены сетевые ресурсы...
(8) я правильно Вас понял - Вы используете компонент ОС "Система архивации Windows Server" для архивирования баз 1С 8.2? какую ОС Вы используете? базы в сетевой папке?

(14)Каким же образом по твоему она должна решить эти проблемы?
VSS отправляет сообщения, однако редко кто их понимает, 1с точно не понимает, поэтому эти проблемы никак не решается.
Копирование идет на живую, как есть, просто моментальный снимок диска в момент времени.

(12) Боюсь ты не понимаешь механику процесса. Сценарий "процессы 1С не узнают, что их кто-то останавливал" и так реализуется, если процесс никак не взаимодействует с VSS. То есть для большинства приложений, включа 1С, Word, Notepad и т.д.

Но этот сценарий не обеспечивает ключевого свойства, не обходимого для бэкапа БД - согласованности. Для этого и нужен VSS API. Когда VSS просит приложение приостановить запись, только приложение знает, что именно нужно сбросить из кэша на диск, чтобы база в сделанном снимке осталась в согласованном состоянии. Подумай о сотнях возможных незавершенных транзакций.

(14) >Что касается работы VSS по сети (точнее по SMB протоколу): запросы компонентов службы транслируются в сеть, иначе бы не работало теневое копирование для общих папок

Насколько мне известно, у VSS нет такого API, для работы по сети. Может уже и появился, тогда буду рад ссылкам на MSDN. Не вижу, как это может помешать работе теневого копирования для общих папок.

Ну и цитата (http://technet.microsoft.com/ru-RU/library/cc771305.aspx) пока остается актуальной: "Создание теневых копий нельзя использовать вместо архивации."

Не будет надёжного бекара.точка

(18) А бемоль будет?

Чем вам SMB не нравится - вся работа по сети транслируется в работу с диском. Соответственно, SMB-сервер может понимать API резервного копирования (и даже что-то приостановить), но передать запрос по сети клиенту он не умеет.

При желании, в код 1С можно вставить "ожидалочку", которая при появлении какого-то файла в определённом месте будет приостанавливаться, и отвечать, что готова к копированию (то есть все открытые сеансы замрут на обработке, которая не обращается к базе данных) - но тогда можно смело просто копировать файл базы и не бояться, что с ним что-то произойдёт.
P.S.  у меня на семёрошных файловых базах так работает.

(15)>VSS отправляет сообщения, однако редко кто их понимает - откуда такая уверенность???
>Копирование идет на живую, как есть, просто моментальный снимок диска в момент времени.
Jump, Вы хоть читали как работает VSS, что значит "на живую, как есть, ПРОСТО моментальный снимок"... совсем не ПРОСТО, перед созданием снимка проводится целый ряд подготовительных операций, в т.ч. и сброс кеша и контроль файлового ввода-вывода.
(16)>Когда VSS просит приложение приостановить запись, только приложение знает, что именно нужно сбросить из кэша на диск, чтобы база в сделанном снимке осталась в согласованном состоянии
Вот тут не могу не согласится!!! 1С должна уметь понимать запросы VSS API, хотя эти запросы может на каком-то абстрактном базовом уровне обрабатывать сама ОС, в которой выполняется клиентское приложение 1С.
(17) Насколько мне известно, у VSS нет такого API, ... Не вижу, как это может помешать работе теневого копирования для общих папок.
Ну как же... Теневое копирование общих папок также использует службу VSS в момент создания теневой копии тома с общими папками. Служба VSS должна же уведомить всех читателей-писателей, которые держат файлы в открытом состоянии, о том что она собирается сделать снимок файла, и делает это... Если служба VSS в сценарии теневого копирования общих папок так работает, значит и при ее использовании службой архивации Windows происходит все тоже самое...
(18) еще бы такие же веские агруметы бы услышать как Ваше высказывание :)
(20) у нас к счастью базы не тронутые на измененеие конфигурации, поэтому встраивать в конфиг семафоры отпадает...

(21)Это и есть "на живую" делается снимок фс на момент времени, такие вещи как сброс кэша контролируются собственно файловой системой, т.е файловая система будет в идеальном состоянии, а вот внутри какой то базы данных могут быть проблемы, т.к приложение не знает про снимок и продолжает писать. VSS не может знать все данные записало приложение или нет, поэтому снимок может содержать недописанный файл.

(18)Как посмотреть.
100% гарантию не получишь конечно, но и полностью битой базы тоже не будет ни при каком раскладе.
Зато есть шикарное преимущество - снимки можно делать как угодно часто не прерывая работы. Т.е оно прекрасно сработает там где не сработает обычная архивация.
Поэтому если использовать теневые копии вместе с обычной архивацией, то будет и стопроцентная надежность, и все плюшки теневого копирования.

(21) >Служба VSS должна же уведомить всех читателей-писателей, которые держат файлы в открытом состоянии

Только тех, которые предварительно зарегистрировались в VSS как читатели или писатели. Разумется, SMB-сервер это делает и сбрасывает свои кэши. Но согласованности базы 1С в бэкапе это не обеспечивает.

(22) Именно.

(22)>т.к приложение не знает про снимок и продолжает писать.
ну и пусть пишет... в описании работы VSS четко же сказано - VSS компоненты в момент когда все текущие операции файлового ввода-вывода завершены уведомляют всех писателей о заморозке файлового ввода-вывода на период создания теневой копии, и уведомляет о возможности начала новых операций файлового ввода-вывода после создания теневой копии и помещения ее в архив... там же пометка, что если компонентам VSS не удастся остановить файловый ввод-вывод на период создания теневой копии из-за интенсивного файлового ввода-вывода, то архивирование завершится с соответствующей ошибкой... Т.е. ситуации когда 1С что-то пишет в базу, а оно частично попало, частично нет - такое не возможно, другое дело что запись в базу одной информации может производиться за несколько транзакций и вот часть из них может быть записана полностью, а часть уже не войдет в теневую копию и запишется в базе после ее создания... Что бы такого не было у 1С должен быть специальный агент архивирования как у Exchange и SQL, а его нет.
В общем я прихожу к выводу, что систему архивации Windows Server можно использовать, но с определенными ограничениями: не делать бекап в пики работы пользователей, а делать его, например, ночью, когда база статична и в информации не происходит изменений; не применять систему архивации Windows Server в случае если требуется интенсивное резервное копирование - каждый час, например...

(25)
>там же пометка, что если компонентам VSS не удастся остановить файловый ввод-вывод на период создания теневой копии из-за интенсивного файлового ввода-вывода, то архивирование завершится с соответствующей ошибкой

Откуда такая информация? Можно ссылку?

(26) http://technet.microsoft.com/ru-ru/library/ee923636(v=ws.10).aspx

(27)Насколько я понимаю это касается только тех кто корректно взаимодействует с VSS.
А в случае с 1с с VSS будет взаимодействовать служба SMB, и она прекратит запись по требованию, но она то не в курсе, что за данные она передает, она тупо выполняет команды 1с на запись и на чтение.

(28) главное что файловый ввод-вывод будет остановлен и накоплен в буфере на период создания теневой копии для архива, а после накопленный буфер запишется в базу... другое дело, что действительно служба VSS не узнает в нужный ли она момент остановила файловый ввод-вывод, например, может 1с-ке еще нужно было сделать несколько файловых вводов-выводов, чтобы привести базу в консистентное состояние... хотя у меня нет информации как 1С работает с базой и хранит ли она что-то в локальном файловом-кеше и сразу все читает/пишет, и как делает операции чтения/записи - за раз одним потоком или частями...

(29)Файловый ввод-вывод в буфере не накапливается в период создания теневой копии.
Смысла в этом нет.
Т.е сама копия делается мгновенно, состояние диска замораживается, и с этого момента операции записи/чтения идут через службу теневого копирования, и начинается чтение замороженных данных и передача в хранилище, а это может занять и больше часа.