gifts2017

Безопасное копирование файловых баз данных 1С (1Cv8.1CD)

Опубликовал Сергей Боровик (BorovikSV) в раздел Администрирование - Сервисные утилиты

Безопасное копирование файловых баз данных 1С (1Cv8.1CD)
При подключенных пользователях!

Эта программа для тех, кто  работает с файловой версией 1С.

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

Обычно заставляют пользователей выйти, делают копию, и потом все входят по новой. Это естественно не нравится пользователям и занимает какое то время (ведь нужно всех оповестить о необходимости выхода, а потом о необходимости входа).

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

И наконец в особо "нелепых" случаях, просто копируют файл 1cv8.1CD, наивно думая что все пучком.

Даже случаи ночных бэкапов, когда предполагается что все уже давно дома, походят далеко не всем. Во первых кто-то может и задержаться, а во вторых может быть работа с базой в режиме 24/7 (диспетчерские к примеру).

Почему же нельзя просто скопировать файл  1cv8.1CD?

Принцип работы 1С, заключается в том, что основной файл базы 1cv8.1CD никак не блокируется. Блокировки накладываются на вспомогательный файл 1cv8.1CL. То есть когда 1С хочет что-то прочитать, или записать то она блокирует 1cv8.1CL с определенными смещениями, которые соответствуют тем или иным таблицам. Когда все, что нужно прочитала (записала), то блокировки снимаются.

В упрощенном виде можно процесс "Блокировка - Запись - Разблокировка", представить как транзакцию. В силу естественных причин они должны быть атомарны (неделимы), ведь иначе получим несогласованные данные, и как следствие заведомо аварийную базу.   

В момент простого копирования, есть очень большой риск, что получите копию с несогласованным данными.  Ведь пока вы копировали 5-й по счету мегабайт, 1С в 1-м по счету мегабайте внесла некоторые изменения. И вы получите копию, где 5-й мегабайт "свежий", а 1-й мегабайт "старый". Другими словами копия получилась несогласованная, аварийная, и она вам обязательно за это "отомстит" в самый неподходящий момент. 

Принцип действия программы:

Программа блокирует необходимые файлы, при этом ждет пока 1С завершит то, что начала. Затем копирует 1cv8.1CD в текущий каталог с добавлением к имени текущей даты и времени.

Если в процессе копирования, 1С решит что-то записать в базу (начать транзакцию), то ей придется дождаться завершения копирования.

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

Как использовать:

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

Что не реализовано, и будет реализовано в следующий версиях:

1) Поддержка командной строки

2) Сжатие копий

Простым копированием, или способом, указанным тут, действовать ни в коем случае нельзя, ибо будете получать аварийные копии!

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
V8DBBackup.zip
.zip 59,30Kb
21.12.14
78
.zip 59,30Kb 78 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Игорь Пашутин (Alien_job) 22.12.14 07:17
Ну в момент включения блокировки не факт что данные корректны. Например движения документа в одно регистре записаны а в другом еще нет. Это, безусловно, способ надежнее "копирования базы за 30 сек" но всё равно доверия не вызывает.
2. Призрак (davdykin) 22.12.14 07:38
Я думаю в данном случаи должно решить задачу теневое копирование тома, допустим с помощью бесплатной программы cobian backup.
3. Сергей Боровик (BorovikSV) 22.12.14 12:04
(1) Alien_job, в момент включения блокировки - транзакция завершена.Данные возможно будут некорректные, но всяко не аварийные. Тем более все жизненно важные операции проходят в рамках одной транзакции
4. AHDP (AHDP) 22.12.14 16:46
(3) Транзакция гарантированно не будет открыта только тогда, когда вам удастся заблокировать все таблицы в файловой БД.

P.S. Опишите пожалуйста алгоритм работы программы.
5. Сергей Боровик (BorovikSV) 22.12.14 20:22
(4) AHDP, Перед копированием накладывается общая блокировка на запись на 1Cv8.1CL. Платформа использует этот же файл для установки блокировки. Получается я не смогу установить блокировку пока есть хотя бы одна блокировка на запись самой платформой, и мне приходится ждать. Но как только я заблокировал, то ждать придется уже самой 1С.
Подвох в том, что сам целевой 1Cv8.1CD платформой не блокируется, блокируются лишь вспомогательные с расширением 1CL. Те кто это не знает как раз и входят в "группу риска" копируя чем не попадя главный файл :)
bayce; sashocq; BigB; +3 Ответить 1
6. Татьяна Крестьянкина (oleg212) 23.12.14 10:16
(2) davdykin, Тоже пользуюсь Cobian с теневым копированием. Справляется прога нормально.
7. Александр Кузин (sashocq) 23.12.14 10:26
(5) BorovikSV, это очень важная информация. Добавьте ее в основное описание программы.
8. Александр Кузин (sashocq) 23.12.14 10:27
У вас там в архиве exe-шник или скрипт? А то неохота тратить 1 $.
9. Сергей Боровик (BorovikSV) 23.12.14 11:21
(8) sashocq, EXE разумеется. Был бы скрипт - была бы статья а не файлик :)
10. Сергей Боровик (BorovikSV) 01.01.15 06:16
(6) oleg212, (2) davdykin, Не задумывались что произойдет, если снимок сделается в тот момент, когда 1С часть транзакции уже скинула на диск?
11. Константин Юрин (kostyaomsk) 08.01.15 19:52
За объяснение на что накладывается блокировка и прочие "радости" при копировании открытой базы спасибки. А вот плохой метод копирования открытой базы
То есть когда 1С хочет что-то прочитать, или записать то она блокирует 1cv8.1CL с определенными смещениями, которые соответствуют тем или иным таблицам. Когда все, что нужно прочитала (записала), то блокировки снимаются.
применим, если просто экстренно нужно получить копию для анализа ошибки или тестирования. Конечно, и это нехорошо, когда в файловой базе работают пользователи.
Платформа 1С 8 так устроена, что держит в ОЗУ до последнего момента какие-то данные для записи до закрытия. Зачем?! Даже разработчики не знают.
12. Сергей Боровик (BorovikSV) 08.01.15 22:15
(11) kostyaomsk,
Платформа 1С 8 так устроена, что держит в ОЗУ до последнего момента какие-то данные для записи до закрытия. Зачем?! Даже разработчики не знают.

гениально!!! Это вероятно новый способ разработки программного обеспечения - держать до последнего момента какие-то данные... Нужно запатентовать технологию, а то гляди разработчики вдруг догадаются, зачем их платформа что то держит до последнего момента....
13. Олег Шалимов (CaSH_2004) 15.01.15 19:31
Очень ждем командной строки
14. Сергей Боровик (BorovikSV) 16.01.15 19:09
(13) CaSH_2004, скоро появится полная распаковка + упаковка. В т.ч. конечно же данные, в XML или бинарном виде.
15. Сергей Боровик (BorovikSV) 22.01.15 16:29
(2) davdykin, А вы уверены в том, что теневое копирование произошло в момент когда 1С завершила процесс записи транзакции???
16. Джо Неуловимый (get-start) 27.12.15 22:48
(3) BorovikSV, имхо, бэкапы нужны для восстановления данных... поэтому тут неприемлема спешка, которая может навредить созданию бэкапа... надо просто приучать пользователей к сообщению "Через 5 минут освободите базу на 30 минут" и всё..-)
17. Сергей Боровик (BorovikSV) 28.12.15 08:31
(16) get-start, может открою страшную тайну, но бэкапы (полный дамп) нужны и для других целей. Например чтобы провести тест на восстановление последовательности, тест на обновление, или просто переслать разработчику.
В боевых условиях сообщение "Через 5 минут освободите базу на 30 минут" - может привести к написанию объяснительной, на предмет того чем же вызвана такая необходимость в разгар рабочего дня.
18. Джо Неуловимый (get-start) 28.12.15 22:52
(17) BorovikSV, бэкап (backup) - переводится даже "возврат"... "резервное копирование"... то есть - после неудачного переноса каких-то доработок, либо элементарно диск посыпался. а вот для разработки/тестов/etc - можно воспользоваться и "быстрым" копированием... даже тем, которое предлагается в статье по использованию WinRar-а: не факт, что "проскочит" какая-то транзакция, которая сильно разрушит данные (возможно это отразится на одном/нескольких документах) и, даже если так произойдёт, не факт, что для тестов/разработок эти документы будут сильно нужны... а экономия времени - значительная (более чем стократ)... далее - мы эту базу не будем переносить на рабочую, а в лучшем случае - будем переносить доработанную конфигурацию, которая никак не повредится при таком "быстром" копировании... в случае неудачи такого копирования (база сильно повредилась) - мы базу НЕ ТЕРЯЕМ... мы теряем только возможность приступить к тестированию/разработке в данный момент... если соотнести стократное ускорение копирования и вероятность того, что оно было зря - можно решить для себя, применять этот способ или нет. только и всего.
по поводу "объяснительной" за сообщение об освобождении базой: конечно, если по каждой ерунде гонять людей, то это приведёт к недовольству и конфликту, но если есть острая необходимость (программист делал какую-то разработку и надо внедрить её в рабочую базу, и для этого, естественно, нужна точная копия... или обновление делается, которое в принципе может криво установиться) - это РАБОТА программиста и не нужно ставить её ниже работы ключевых пользователей. если ключевые пользователи так будут реагировать на действия программиста - они рискуют остаться без поддержки..-) надо уважать не только свой, но и чужой труд, который, тем более, направлен ради твоей же (ключевого пользователя) работы... как-то так, например.

резюмируя всё вышесказанное: я ничуть не принижаю значимость данной вашей обработки, но на мой взгляд она как бы между двумя стульями оказалась - она и не настолько "скоростная", как если бы через прямое архивирование, но и не такая точная, как если бы выгрузкой ИБ... таким образом - разработка мне кажется интересной с точки зрения понимания механизмов работы и умение внедряться в эти механизмы...
19. Сергей Боровик (BorovikSV) 29.12.15 08:12
(18) get-start,?

она и не настолько "скоростная", как если бы через прямое архивирование,


Вы шутите? как может быть "прямое" копирование, быть дольше прямого "архивирования"? :) что то курите? :)

и чем же она по вашему отличается от winrara? WIN API с ней как то по особому работает?
единственное на чем может быть задержка - это на ожидании завершении транзакций клиентов. Маловероятно что клиент что то массово перепроводит в этот момент (в одной транзакции), поэтому задержка стремится к нулю.
При активных же пользователях - копирование же WINRARом - гарантирует косяки в копии.


резюмируя всё вышесказанное:
1) я не понимаю зачем разводить демагогию насчет способа копирования, если этот способ копирования отличается лишь наличием блокировки перед ее началом процесса.
2) Как может быть лучше или равнозначен способ, при котором целостность не обеспечивается в принципе (простое копирование, или Winrar без сжатия)?
3) по моему за способ работы с базой "не факт, что "проскочит" какая-то транзакция" - нужно расстреливать
20. Джо Неуловимый (get-start) 30.12.15 06:11
как может быть "прямое" копирование, быть дольше прямого "архивирования"?
мы определились, что используем этот способ ТОЛЬКО для переноса базы клиента для некоторых доработок... и даже копирование на флэшку архива 1cd-файла гораздо быстрее/оптимальнее (по заполнению флэшки), чем копирование его самого (он хорошо сжимается). а если говорить, что копируем базу через rdp|ammyy|teamviewer|server (то есть через интернет или, последний вариант, по локальной сети) - то это вообще убийство качать неархивированный файл. мало того - я даже dt-файл архивирую (хоть он и не сжимается) - чтобы в случае ошибки развёртывания базы заранее исключить вариант "кривого копирования" и меньше возиться потом. в вашем случае - после "прямого" копирования (допустим на тот же диск, где база) - по этой логике нужно будет ещё архивировать. то есть - дополнительное время на "прямое" копирование и на "лишние движения" по архивированию... ну, либо дольше копировать...

Как может быть лучше или равнозначен способ, при котором целостность не обеспечивается в принципе (простое копирование, или Winrar без сжатия)?
самый первый комментарий говорит, что и ваш способ не обеспечивает целостность...может менее "аварийная" ошибка, но тем не менее - не расстрелять, а лишь оторвать руки (по вашей логике..:-) )

по моему за способ работы с базой "не факт, что "проскочит" какая-то транзакция" - нужно расстреливать
ещё раз - поскольку этот перенос ИСКЛЮЧИТЕЛЬНО для разработчика (не для бэкапирования базы перед изменениями либо регламентного), разработчик САМ решает как ему поступить... процитирую себя
в случае неудачи такого копирования (база сильно повредилась) - мы базу НЕ ТЕРЯЕМ... мы теряем только возможность приступить к тестированию/разработке в данный момент... если соотнести стократное ускорение копирования и вероятность того, что оно было зря - можно решить для себя, применять этот способ или нет.
согласен, что в случае вашей обработки - это, конечно, не "стократное ускорение", но тем не менее - быстрее.
21. Vladimir Ru (9322304@gmail.com) 14.07.16 10:19
А можно еще добавить в ком. строку переметр - ПРЕФИКС ?
Было бы здорово, если бы был режим без индикации, с возможностью вывода данных в файл лога
а так вроде работает....
22. Vladimir Ru (9322304@gmail.com) 14.07.16 10:25
не понятно, как связать эту утилиту в процесс автоматизации....т.е. вписать в другой скрипт.
проблема в том, что не известно, какой файл она создаст, чтобы после ее завершения передать его архиватору с последующим переносом на FTP в хранилище
Вариант скрипта
V8DBBackup.exe
RAR *.1CD -Исключить 1C8db.1cd -удалитьИсх
Upload2FTP *.rar
если НЕ Ошибка Тогда delete *.rar
23. Сергей Боровик (BorovikSV) 14.07.16 17:21
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа