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

В СКЛ - без проблем.
В ДБФ - копируй в обед - обычным раром и ночью - когда никто не работает. Максимум потеряются пара документов (при обеденной копии). Каждый час - это круто.

0. УРБД можно юзать в разделенном режиме. Переферийная в этом случае - копия.

Без потерь - только в SQL.
Обычно делают так:
- полный BACKUP базы - раз в сутки;
- Transaction log(это изменения базы) - каждый час.
Отключать пользователей не надо.

Мэт, объясни пожалуйста конкретней, что за разделенный режим, и что за переферийная, как копия. Все пользователи (включая админа)при работе с 1С на равных правах, и это не должно нарушаться для сохранения целостности базы. Наша база в DBF.

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

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

Планировщиком мы бы с радостью, но он не копирует открытую базу, точнее в планировщике мы выбирали Buckup, который и не копирует, а функции копирования в планировщике нет. Но хорошую быструю копию делает Windows Commander (WC) и почти всегда успешно (если делать замену изменившихся), но в WC какой то дурной планировщик. Что можно еще придумать?

Появились у кого какие идеи?

(0) Да, можно.
Но надо сначала копировать в буфер и отслеживать изменения dbf - если для каких-то DLL они были, то докопировать их из базы. У меня скоро появится готовая прога. Еще есть у Гендальфа (платная).

Но вообще правильный путь это делать - ставить SQL-сервер, и там можно бэкапить по таймеру хоть каждые 10 минут. Бэкапить, разумеется, только изменения (транзакции), а в начале дня - всю базу целиком (тоже средствами SQL).

А как можно запланировать КОПИРОВАНИЕ определенных файлов? Желательно, что бы было только замещение более старых.

(0) Можно как угодно, если запись в базе не ведётся.
Нельзя, если запись ведётся - критично для самой базы (для оригинала).

+Кластер, реальная копия на удаленном ПК.

Я ошибся в (9) вместо DLL следует читать DBF. :-)

(10) Надо получить дату и время файла и сравнить с сохраненными в таблице значений. Т.е первый шаг: читаешь атрибуты исходных файлов в ТЗ. Второй шаг: копируешь файлы на новое место. Третий шаг: сравниваешь файлы в папке с базой (откуда мы копировали файлы) с ТЗ. Если есть отличия, то докопируешь те файлы, по которым они есть, и переходишь опять на шаг 3, до тех пор, пока различия не исчезнут. Так ты получишь копию базы, в которой нет кривых DBF.
Далее их надо заархивировать и ... ну вроде и все.

(11) да ну? и чем же чтение файлов может повредить операциям записи?

(13) и брюки превращаются, и брюки превращаются ..... (Бриллиантовая рука).
ЗЫ: Зачем ДБФ отслеживать - отслеживай записи в ДБФ.
Ставлю два к одному, что по вышеуказанному алгоритму ты не закончишь копирование пока юзеры не прекратят свою работу

14. Он этого еще не знает. ;-)

Спасибо за алгоритм, но программировать я не собираюсь. Я хочу делать копию стандартными приложениями. Мы делаем копию с базы в ручную из под WinCom прямо по работающей базе, занимает это пару секунд. При этом данные копируются полностью (даже открытые) и практически всегда коректно. Но не будешь же копировать в ручную каждый час. Как можно автоматезировать этот процесс?  При этом архивация Buckup бессмысленна, она не архивирует открытые файлы.

Да здравствуют армянские комсомольцы...

По закону подлости когда понадобится копия - она будет битая... Ибо копирование может с какой то долей вероятности прийтись на момент, когда запись в ДБФ добавлена... а заголовок еще не исправлен... Придется ДБФ восстанавливать вручную... С точки зрения 1с он будет дефектным...

Чем больше юзеров и чем более они активны - тем больше вероятность этого...

Пара секунд - это пока база маленькая... Будет метров 500-800 - пролетишь...

Удачи....

Да... очередное изобретение велосипеда...
(17) Петь, не только... Ибо с точки зрения 1С запись производится не в один файл...
Впрочем... можно пожелать успехов... тем, кто применит данную "технологию"

Эх молодость, недоверие, поиски чего то своего. Это пройдет.
Просчет вероятности получить битую. Да делай два раза в день "битую" - вероятность уменьшится.
Да не делится жизнь на белое и черное. Нету в ней идеального ничего. И не будет.
Каждый выбирает для себя дорогу сам. Так и с Первой заповедью (Сохраняйся и предохраняйся): либо качество 100%, либо время минимальное. Обычно останавливаются на чем то среднем.

(13)
>>да ну? и чем же чтение файлов может повредить операциям записи?
Сразу видно, что ты ни разу не наблюдал как такое происходит. А всё дело в том, что чем бы там не производилось копирование - происходит захват таблиц базы нештатными средствами с точки зрения 1С. В итоге запись самой 1С в эти файлы может обломиться, да ещё так, что 1С об этом не узнает. А потом начитают вылазить и кривые остатки, и неверные итоги колонок, и ещё масса милых вещей.
Уже сколько было веток на тему, что из-за антивирусов бьются индексы и сами DBF-ки, а ведь антивирусы ничего в базу не пишут - только читают...
Конечно, если база меньше 100 мб и копирование её занимает 2 сек, как говорит (0), то вероятность таких глюков крайне низка. Тем не менее заводить за правило такое копирование, да ещё и ставить его в расписание - практика порочная.
Если дело касается больших баз, то я таких копирователей гоню в три шеи.

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

фздеть - не тележку мазать...


(0) Слушай Иама-а.... Кратчайший путь к покупке вазелина...

Уважаемые BorisG & 427.
А позвольте Вас спросить : исходя из каких предпосылок происходит ваше утверждение о невозможности копировать базу в  время работы?
1.Кто сказал что на время изменения записей файла ДБФ (влияющих на заголовок) не блокируется весь файл?
2. Откуда берется утверждение, что при выполнении транзакции, влияющей на несколько файлов, эти файлы не блокируются?
А нельзя-ли кроме аргументов типа - Кратчайший путь к покупке вазелина... - приводить какие-нибудь более обоснованные аргументы?
И, возможно, все-таки изучить хотя-бы основы реляционных баз перед тем как вступать в подобные дискуссии?

Насчет "все-таки изучить хотя-бы основы реляционных баз перед тем как вступать в подобные дискуссии?"

ЗАДАЙ ЭТОТ ВОПРОС РАЗРАБОТЧИКАМ...

поставь точку останова в модуле документа.... Тормозни отладчиком... И скопируй ДБФ тем же фаром .... с установленной птичкой "Копировать открытые для записи файлы".....   ПРИЯТНЫХ ТЕБЕ ОТКРЫТИЙ!

P.S. - программа в режиме "Предприятие" д.б. открыта немонопольно... впрочем, если она монопольно - ты ничего не сделаешь....

P.S. выводы сделай сам....

Пункт 2
"2. Откуда берется утверждение, что при выполнении транзакции, влияющей на несколько файлов, эти файлы не блокируются?"

Даже нормальная блокировка участвующих в транзакции файлов  оставляет дыру, при попадании в которую можно иметь копию базы, в которой часть файлов - имеют состояние ДО транзакции, а часть - ПОСЛЕ....

P.S. есть еще одни грабли... время копирования... на которые налетишь при увеличении размера базы...


Вот такая она, 1С.... Не одидал? Хочешь поговорить об этом?


P.S. есть по моему, гендальфовский "Стражник"... в котором эти проблемы решены... как это реализовано - не знаю...

(21) Повезло. Либо базы были маленькие. Я тоже с чистой совестью делаю копии с открытых на запись баз, меньше 500 Mb. Но если на тебя никогда не падали сосульки, сие не значит, что нет таких, на которых они падали (и даже убивали насмерть).
(23)
1) Весь файл DBF никогда не блокирируется в разделённом режиме работы, ибо это невозможно при том способе работы 1С с файлами, который реализован в V7.7
2) Эти файлы не блокируются:
а) по той же причине, что и 1)
б) потому как я сам делал такие копии и лицезрел своими собственными глазами, как какая-нибудь DH...DBF ссылается на какой-нибудь ID документа, в то время, как в 1SJOURN такого ID не значится.
...
Любители веских аргументов могут провести ряд экспериментов.
Например, если открыть журнал регистрации на просмотр FARом и одновременно входить, выходить из базы, что-нибудь в ней делать - можно заметить, что записи о действиях почему-то не всегда в появляются в журнале. Когда-то я ломал голову, наблюдая, что подключения нет, а отключение есть, пока не связал эти явления со своими же действиями по захвату файлов.

Один мой приятель делал копию таким образом (на работающей ДБФ базе). Когда захотел перейти на сиквел нарвался на проблемы с базой. Возможно, что проблемы были связаны с други, а возможно что и нет.
По поводу блокировок (все имхо по ДБФ). Не уверен что блокируются целиком файлы, а не записи. Не уверен что когда работает какая-нить обработка и лопатит базу, что где-то что то блокируется. Не уверен даже что при такой операции проведения (вроде как неявно начинается транзакция) в модуле проведения написано изменение периодическизх реквизитов и ли еще чего-нить. НЕ уверен что заблокированно сразу все. И потом. А как быть с кэшами (или буферами).
Короче я ни когда не копировал так - чтоб не создавать потенциальные возможности ошибок.
А вообще ...... как-нить на сетке поэкспериментирую

23. Да... уважаемый... а позвольте спросить,  много ли работал с 1С и базами данных, чтобы утверждать такое?

Для начала в качестве отступления... Несколько месяцев назад был случай у клиента... Админ, начитавшийся подобных на форумах "советов", делал копии "на лету". Когда произошел сбой, единственной полноценной копией оказалась копия, сделанная во время регламента моей сотрудницей...

Ну и... дополню сказанной pit'ом...
Как это реализовано у Гендальфа в Хранителе V, написано в ФАК'е...
Ответ на вопрос "Можно ли архивировать открытые информационные базы?"
http://www.backupper.ru/FAQ/040617.024.htm

Только вот незадача... даже установка флажка "Контролировать целостность архивных данных" не всегда спасает... Причины, я думаю, известны ;-)

Так что... уважаемый, если есть желание обсудить КОНКРЕТНЫЙ алгоритм... всегда рады... ;-) Ежели это пустое сотрясание воздуха... увы...

PS: Прежде, чем давать "совет", следует основательно ознакомиться с предметной областью... Форум ведь читают не только те, кто отдает себе отчет, что делает...

Не пойму, а чем не нравится УРИБ для копий? Или тот же МОД. Синхронизацию можно делать каждый час, к примеру.

Насчет копирования с остановленной в отладчике программой - сейчас попробую. Результат выложу.
Время копирования не считаю критичным.
База ~240 МБ; Сервер Р4 1700 мГц; Рабочая станция - место хранения архива Celeron 1700 (при этом и на сервере и на станции работают достаточно интенсивно + еще 4-е рабочих места); Сетка - 100 мБ/с; ОС - ХР; время архивирования при сжатии WinRar (файлы *.CDX исключаются) 12...14 мин.
База архивируется каждый день.
Восстанавливалась из архива раза три. Ни одного сбоя

28. А разве это обсуждают? Про это намекнули еще в(2)...
Тут "гениальные изобретатели велосипедов" ;-)

29. Да... великий опыт... ничего не скажешь... куда уж нам... ;-)
Только вот такой же, как и ты, админ... пришел, где базы были поболее... и машин не 4, а под 50... После того, как выяснилось, что восстанавливать не с чего, лепетал... "Я вегда так раньше делал... ни одного сбоя..."

240 МБ да еще если работа не очень интенсивная... может и прокатить.... А на объемах свыше 500 МБ точно загибаться начнет... А при интенсивной работе - и раньше...

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

Время копирования критично... Можно часть скопировать ДО транзакции - часть ПОСЛЕ... Вот это будет очень хорошей плюхой...


насчет отладчика - можешь не проверять..Ввпрочем, делай... Только ПРЕДПРИЯТИЕ д.б. в НЕМОНОПОЛЬНОМ режиме... Отладчик запустится - не боись....

На самом деле существует способ прямого копирования. Если база на RAM-диске.

33. Ну уж тебе то такое говорить... Да хоть на чем, ибо 1С не умеет их различать ;-)
Просто с RAM-диска скорость копирования выше... однако незавершенные транзакции определяются на рабочей станции.

Выкладываю результат копирования базы при остановленом выполнении модуля документа :
Документ в скопированний базе, как и ожидалось не проведен. Желающим могу дать разъяснения почему так.

Насчет ковыряная базы Far'ом - механизм блокировки FARа отличается от механизма блокировки Win (вернее не FARа а его вьювера). И вот его использование как раз и представляет опасность. Пользуйтесь штатными средствами и все у вас получится.

Насчет механизма блокировок (в т.ч. и Win-провайдера ДБФ) есть масса литературы. Но вкратце напомню :
1. При применении механизма пессимистичесой блокировки (который применен в 1С)
провайдер пытается получить доступ до начала корректировки записи.
2. В случае если в доступе отказано - провайдер будет в течении n сек.(время ожидания захвата...) пытаться получить доступ. Если доступ не будет получен - провайдер сгенерирует ошибочную ситуацию ( и 1C выдаст сообщение о ошибке захвата таблицы).
3. Если доступ будет получен - провайдер заблокирует запись.
4. Все изменения в запись вносятся не непосредственно в дисковом файле, а в буфер провайдера. И записываются в дисковый файл cпециальной командой провайдера (Commit).
5. По окончании корректировки записи все изменения записываются в дисковый файл. (и ТОЛЬКО тогда).
6. Снимается блокировка с записи.
7. В случае, если корректировалась новая запись, то на время ее записи в дисковый файл также блокируется и заголовок файла. (кто не увидел признаков этому - могу дать пошаговую инструкцию как посмотреть).

PS. таким образом информация в дисковых файлах всегда согласована и всегда меньше фактически внесенной на объем информации хранящейся в буферах провайдеров. Т.е. полноценную копию можно получить только при завершении работы всех экземпляров 1С. Однако для нужд резервного копирования УЧЕТНЫХ программ отставание резервной копии от фактической базы не является критичным (или определяется в каждом отдельном случае индивидуально).

Вдогонку.
Хотелось бы услышать аргументы повесомее чем был случай, не думаю что блокируются и т. д.

Если факты противоречат теории - тем хуже для фактов...

На 31.
Насчет опыта. В 1998-ом году на предприятии, где я работал стояло 34 машины.
Сервер Novell 3.11 на P266. Станции начиная от 486 и кончая P266 (время тогда такое было). База ДБФ. Работа с базой в Clipper 5.1. Там механизм транзакций отсутствовал как класс. Все блокировки должны били быть прописаны руцями. Так вот - архивное копирование протянуло 4 года. Правда с продуманным и проработанным механизмов тех же блокировок. Не думаю, что спецы из 1С владеют этим вопросом хуже, чем допустим BorisG.

(38) Закон Миллера: Ничего нельзя сказать о глубине лужи, пока в неё не попадёшь.

я тащусь...

(35) В 1С для работы с ДБФ использована коммерческая компонента ... которая даже в момент выхода 1С7.7 в свет не являлась самой лучшей...
Разработчики там наложили целый вагон болтов ... как на основы реляционных СУБД.... так и на реализацию стандарта ДБФ...

А если учесть, что сама 1С сделала еще ряд серьезных отступлений от стандартов....

Так что все твои изыски... можешь оставить себе... и все описанное тобой не совсем истинно отражает суть вещей...


"Однако для нужд резервного копирования УЧЕТНЫХ программ отставание резервной копии от фактической базы не является критичным (или определяется в каждом отдельном случае индивидуально)."

Ошибаешься... Резервное копирование для УЧЕТНЫХ программ ДОЛЖНО ОБЕСПЕЧИВАТЬ 100% ИДЕНТИЧНОСТЬ копии...  Иначе можно потерять денежку... в учете ... и в конечном счете разориться....

Вдогонку.
Все выше изложенное не исключает архивирования баз при закрытих экземплярах программы. Но в случае бессбойного архивирования в процессе работы сократит время восстановления утерянных данных (не базы) на порядок. Так что руки никто никому не ломает - считаете лишним не пользуйте (То BorisG & Ko).

Заплати 50 (или 75 - не помню) баксов за программу резервного копирования для 1С ... и спи спокойно...

Там люди специально занимались этим вопросом....

"Хранитель"....  или "Стражник" кто разработчик последнего - Боря скажет...
я не помню.... но мы его купили....  Хочется жить в сухости... а обычные прокладки слабо впитывают влагу....

Я тащусь (С)(40).
Аналогично...
Хотелось бы такиж услышать, а лучше увидеть хоть одно решение обеспечивающее 100% ИДЕНТИЧНОСТЬ в 100% случаев хотя-бы в одной какой-нибудь области деятельности человека.Или 100% надежный компьютер, обеспечивший 100% надежную платформу для такого решения. Или человека неошибающегося на 100%, работающего за 100% надежным компьютером, обеспичивщего 100% надежную платформу для такого решения. И т.д. и т.п.

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

Другое дело, что прочитанная копия может быть некорректной/неактуальной, но тогда надо сверить дату-время файла DBF, и докопировать его в буфер (папку в каталоге TMP) еще раз. А архивировать rar-ом уже буфер.

Щас выложу свою прогу, в которой это реализовано.

http://x-romix.narod.ru/backup.zip

(43) Чем решение в (44) не катит в плане 100%?

(46) а ты не догадываешься?

(44) "О сколько нам открытий чудных готовит просвященья дух..." (С) А.С.Пушкин

Romix, пытались запустить твою программу, выводит ошибку при работе с временными файлами. То ли у нас 1С не так настроен (не назначен каталог временных файлов, если да то как?), то ли твоя программа написана под твой компьютер и пути на нем (хотя пытались вставить и свои пути). Посмотри на ошибку и посоветуй как исправить:

Исполняемый файл архиватора: C:\Program Files\WinRAR\WinRAR.exe

Каталог временных файлов: C:\DOCUME~1\9335~1\LOCALS~1\Temp\Архивация1С

Расширения (типы файлов) для архивации: dbf,dd

Файл не был правильно записан: 1Cv7.DD!

Строка запуска: "C:\Program Files\WinRAR\WinRAR.exe" a  "C:\Бухгалтерия 1С\Магазин 2002 бух\Архив\Бух_2004_08_23__11_45_33.rar" "C:\DOCUME~1\9335~1\LOCALS~1\Temp\Архивация1С" -m1 -s

Код возврата = 1

(0)два года назад делал нечто подобное:
http://1c.proclub.ru/modules/mydownloads/personal.php?cid=5&lid=2008

2(24)pit, есть вопросы по твоим постам:

поставь точку останова в модуле документа.... Тормозни отладчиком... И скопируй ДБФ тем же фаром .... с установленной птичкой "Копировать открытые для записи файлы".....   ПРИЯТНЫХ ТЕБЕ ОТКРЫТИЙ!" - Что будет-то, сам проверял?

"Даже нормальная блокировка участвующих в транзакции файлов  оставляет дыру, при попадании в которую можно иметь копию базы, в которой часть файлов - имеют состояние ДО транзакции, а часть - ПОСЛЕ...." - и это тоже как-то не понятно..., ты случаем не попутал со SQL вариантом? Ибо в dbf нет такого, что ДО и ПОСЛЕ транзакции, есть только ПОСЛЕ. Так что максимум, что может быть, так это при завершении транзакции не все инсерты будут добавлены.

1. Проверял...
2. При попадании копирования на транзакцию (при увеличении базы вероятность увеличивается)... может быть так - в ДН НЕ ЗАПИСАНА шапка дока, а в ДТ - есть строки документа...

То 49.
Посмотри параметры командной строки WinRar для открытия файлов в разделенном режиме. Должно быть что-нибудь типа -dh

2(52)pit, ну тогда колись, куда именно именно ставил точку останова и какие файлы блокируются? У меня не получилось повторить твое.
Так на это есть простой аргумент: если транзакция не закончилась, значит она нам не нужна. И восстанавливать архивы, сделанные на ходу стоит через ТиИ с очисткой. Так все следы незаконченной транзакции устранаются, что в принципе и нормально.

Точка останова на одной из первых строк ОбработкиПроведения... Транзакция неявно уже запущена самой платформой... Почитай о гендальфовском Хранителе - там эта проблема решается повторным копированием...


Естественно, такие архивы восстанавливать через ТиИ...  Но есть некоторые ошибки, которые ТиИ не обрабатывает - например, количествыо записей в файле и заголовке разное.. И еще некоторые..
Ибо закон падающего бутерброда ...

Так накуа мне такой архив?
Вообще накуа архив, в достоверности данных в котором я НЕ УВЕРЕН?


Хотя копировать можно... А вдруг повезет и архив будет целый?
Хотя опять таки - размер базы свыше 500 метров и активная работа 15-20 юзеров практически дают битый архив... на виндовых серверах... они медленные...

Дополнение к (49)
У нас на компьютере вообще нет папок указаных в пути
C:\DOCUME~1\9335~1\LOCALS~1\Temp\Архивация1С
Может это путь по умолчанию в 1С, или WinRar, или данной программе. Но мы переписали все пути в ручную, искали в отладчике 1С эти слова (их нет ни где), все без толку.

2(55)Либо ФАР у меня другой сборки (1705), либо одно из двух. Точку останова ставил я на 5-ой строке. Ну заголовки- это не проблема, есть лечилки этого. Заголовки можно повредить и в процессе работы, дернуть линк и т.п.
Все в мире относительно...

+(57)Так архивы делать нужно не по сети, а на самом сервере. Чтож за идея такая... по сети.

+55 Хранитель при интенсивной работе с базой и большом размере базы даже теоретически не успевает делать успешной копии, посему от этой "затеи" лучше отказаться.

То 55.
Что-то не верится в искренность товарища 427-го.
Если точка останова на первых строках модуля документа то транзакция как правильно было замечено начата и даже во временных файлах ВОЗМОЖНО сделаны какие-то изменения. Но в рабочие файлы не внесено ни одной записи и ни одна запись во всех файлах, участвующих в транзакции не изменилась.
И не изменится до строчки КонецПроцедуры.
Более того никаких изменений не внес в базу также ни один пользователь.
Для эксперимента вставьте в модуль документа цикл, для задержки выполнения и во время проведения такого документа попробуйте провести другой.

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

Вдогонку 60.
Таким образом архив всегда содержит СОГЛАСОВАННУЮ копию базы (либо до начала внесения изменений либо когда уже ВСЕ изменения в базу записаны).

(49,56) А если в базе никого нет, архивирует?
Может, не воспринимает длинные пути к папке temp, а попробуй туда что-нибудь короткое вписать (и эту папку создать). Т.е. вместо КаталогВременныхФайлов() и т.д. напиши, например, "c:\temp\Архивация1С". Я завтра тоже на другой системе потестю, сообщу что получилось.

(53) У меня сначала копирует файлы во временную папку, а потом их архивирует...
Т.е. rar тут ни при чем...

(59) Всегда есть моменты затишья. И, потом, если работают так уж интенсивно, то безусловно нужен SQL. Кроме того, у меня происходит не полный цикл копирования, а докопирование только измененных файлов DBF.

(57) кстати, Фар у меня 1.63... 17хх действительно работает чуть по другому...

(60) остановка в отладчике ... позволяет посмотреть, как можно скопировать залоченные 1С файлы...  А вообще - вперед и с песней...

(63) "И, потом, если работают так уж интенсивно, то безусловно нужен SQL."
А зачем? ДБФ работает быстрее... терминал тоже рулит...  А скульную надо перепахивать для скорости...  Если это бухия... ну уж нах... ее трогать. До первого обновления.

(64-3) Разработчики движка/конф 1С не первый год что ли баги не могут в SQL-бухии поймать? Или только скорость имеете в виду? Если рецепты "перепахивания" всем известны, то просто удивительно, что до разработчиков они не доходят. У них что ли автоматического тестирования нет, или теста производительности? НЕ ВЕРЮ. :-)) Вообще, что-то они в этих DBF-ах имхо застряли: каменный век... :-)

(64-2) Сейчас попробую свою прогу на это натравить... Может, надо по-хитрому файлы копировать, а не фс.СкопироватьФайл()...

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

// ********************
Процедура ОбработкаПроведения()
   Регистр.Остатки.Количество=10;
   Предупреждение(\"Привет 427!\"); //в этот момент я копирую базу - все ок...
   Регистр.Остатки.ДвижениеПриходВыполнить();
КонецПроцедуры

В монопольном режиме, да, все залочено, и копирования не происходит (программа корректно выдает об этом ошибку). А в НЕмонопольном режиме копирование работает как надо (я так думаю, что лочится в НУЖНЫЙ МОМЕНТ - в момент ДвижениеПриходВыполнить() - только кусок файла, и любой читающий клиент ждет, пока этот кусок не будет разлочен - во всех операц. системах так вроде сделано).

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

(27, BorisG) У меня в (45) вроде так и сделано, как написано в этом (27) факе от Гендальфа. То есть, докопирование отдельных файлов, если в них были изменения.

(64)->(65)

Нда... Давно такой [yb я не видел....

(66) Разработчики движка/конф 1С не первый год что ли баги не могут в SQL-бухии поймать? Или только скорость имеете в виду? Если рецепты "перепахивания" всем известны, то просто удивительно, что до разработчиков они не доходят. У них что ли автоматического тестирования нет, или теста производительности? НЕ ВЕРЮ. :-)) Вообще, что-то они в этих DBF-ах имхо застряли: каменный век..."

Ну разработчики я думаю, поумней тебя.. Вот и возятся с ДБФ версией...
Ибо максимум 3-4%  бухий и не более 10% ТиС вертятся под Sql.

   А насчет пофиксить баги... На хиппе не один год выложена тестовая обработка. Которая нормально отрабатывает в ДБФ и либо валит Sql вариант, либо дает неверные результаты...

   НЕТ В 1С тестирования... Ни движка, ни конфигураций.  Четыре последние редакции по сообщениям пользователей правили суммвые разницы в бухии. Вчера очередную ошибку поймали на 4.60.  Вот такое там тестирование.  Тестирование и документирование - ЭТО ДЕНЬГИ. Немалые деньги. Которые 1С экономит.

  А по поводу копирования - флаг тебе в руки. В гендальфе, я думаю, разработкой Хранителя занимались люди гораздо грамотнее тебя. И он проваливается. Делай выводы. Поднимай квалификацию....

P.S. - база, кстати, лочится ВСЯ. Но по своему....

пит ты обращаешь внимание на этого умника... забей... то что он самый умный мы уже знаем

Да, кстати...

Типичный совет для счастливых обладателей Sql движка при восстановлении ГП выдает НАРОДНАЯ МУДРОСТЬ с т1с

выгрузить в ДБФ
восстановить ГП
загрузить в Sql

На что то наталкивает?

(72) слушаюсь и повинуюсь....

Romix, программа вроде заработала, архивирует файлы, но 500 Mb он архивирует
примерно 3 мин (не зависимо от степени сжатия 1 или 3). На целостность архивируемой базы не проверяли.

(72) Самый умный здесь Волшебник. Я только учусь. :-)

(75) Попробуйте восстановиться в тестовую копию базы.
А что SQL не поставите?

На 500 метров СКЛ в самый раз...

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

(78) Можно закинуть ярлычок в папку Автозагрузка.
Тогда при заходе юзера в систему (надо выделить какого-нибудь ответственного за это дело юзера) будет делаться бэкап.

Можно и планировщиком.
Вам как лучше - чтобы на сервере само все крутилось, или чтобы юзер видел что происходит?

(+79) Кстати, удалось ли восстановиться в тестовую базу из копий? Проходит ли Тестирование и Исправление (или выдает ошибки)?

(all) мои 5 копеек
Тему даже не стоит обсуждать.
subj вообще не имеет места ни при каких обстоятельствах.
Если будете отвечать за базу головой ( или чем то очень важным для Вас) то сами
откажитесь от subj, иначе почему бы не поэксперементировать за  деньги работодателя.
Проблемы при subj которые могут возникнуть:
1.часть информации до транзакции часть позже на одном dbf файле.
2. Документ в копию запишется по старому а проводки, движения к нему по новому.
3. Аналогично один документ Док1 может быть записан на старое соответсвии (скажем на момент как до копирования), другой документ Док2 может быть записан как измененый во время копирования. А если между Док1 и Док2 есть какое то отношение в базе данных?
4. "коллизии" 1-3 могут быть не только между документами но спр-документ, константа-документ и.т.д.
5. исходя из 1-4 чему после записи будет соответствовать журнальный файл?
6. сожет возникнуть несоответсвие ( и возникнет ) между dbf и cdx файлом
6. Т.е. при subj  c  большой вероятностью может быыть нарушена целостность
данных в БазеДанных - ценность такой копии очень сомнительна.
Подойдем к проблеме с другой стороны у меня база dbf под 3Гб + поддиректория с сертификатами обычное Windows копирование из одной папки в другую занимает не более 10 минут (точное время даже не засекал). Если стоит из 10 минут рисковать базой то флаг Вам в руки.
(Аналогия из жизни если Вы едете на машине один с какой максимальной скоростью Вы можете позволить себе ехать, и тот же вопрос если Вы едете со всей своей семьей ).
Если у Вас супернепрерывная работа с базой то было уже предложено решение даже
в этой ветке ( см 28 ).
(0) В заключение хотелось бы услышать хоть одно разумное обоснование subj

(81) Разумное обоснование ?
16 лет опыта работы. Всю жизнь с СУБД (еще на ЕС ЭВМ). 1С-овского - 7 лет. С самого начала (с 6.0) ДБФ-ные базы копировал и днем и ночью (из шедулера). Восстанавливать пришлось из копии раза 4-5. Это для клиента. Один раз была проблемка - да, фигня получилась с двумя доками. Решилось за 5 минут. Сам всю жизнь таскаю домой и разворачиваю базу, скопированную с открытых файлов. Почему все работает ? Наверное, руки у меня кривые, вот и получается почему то.

А если попробовать так: создать пустой документ в базе и в модуле его проведения (база в это время будет заблокирована транзакцией) вызывать внешнюю программку бэкапа, после окончания которого выходить из модуля проведения.
PS. На правильность не претендую, но так, в качестве идеи...

(81)

>1.часть информации до транзакции часть позже на одном dbf файле.

 В проге (45) я докопирую измененные файлы, и только потом (когда файлы стабилизируются) их архивирую rar-ом

>2. Документ в копию запишется по старому а проводки, движения к нему по новому.

 то же самое: если после копирования программа обнаружит устаревшие файлы (пока прога копировала, они изменились), то докопирует их.

3. Аналогично один документ Док1 может быть записан на старое соответсвии (скажем на момент как до копирования), другой документ Док2 может быть записан как измененый во время копирования. А если между Док1 и Док2 есть какое то отношение в базе данных?

то же самое

4. "коллизии" 1-3 могут быть не только между документами но спр-документ, константа-документ и.т.д.

то же самое

5. исходя из 1-4 чему после записи будет соответствовать журнальный файл?

 рассогласованные данные невозможны: при такой технологии (докопировать устаревшие файлы) они всегда будут согласованы
 
6. сожет возникнуть несоответсвие ( и возникнет ) между dbf и cdx файлом

 я cdx не архивирую.

(83) Не будет она заблокирована. Попробуй в пустой базе создать док, поставить в его модуль проведения Предупреждение("!!!"); и скопировать базу

Твое "докопирование" на базе размеров от Гб при работе 15-20 человек закончится вместе с окончанием работы последнего пользователя...

Еще раз... в 1с формата DBF нет такого понятия До и После транзакции. Есть всегда После. Т.к. транзакция обрабатывается на стороне клиента и запись в файлы БД производится только в момент фиксации транзакции. И если начать копировать файлы в момент фиксации транзакции и закончить копировать до внесения всех инсертов, то тут и возникает проблема, но она устраняется ЛЕГКО ТиИ с очисткой. Что весит, то удаляем. Действительно, это не хорошо. До все данные, которые были - остаются.

(82) Давай не будем ни про руки ни про кто сколько работает.
Если ты переходишь дорогу не глядя на светофор это еще не значит что все так должны делать. В твоем ответе нет обоснования.
"Один раз была проблемка - да, фигня получилась с двумя доками. Решилось за 5 минут" - А если бы ты не увидел этой "фигни" несоответсвия а скажем налоговая увидела , или из-за этого суперисказилась бы прибыль в оперативном учете?
(82,all)Ответьть всего на два вопроса
1.Зачем делать как в subj
2. насколько для вас критична целостность данных в копии базы данных.

(88)
1 - Потому как первая заповедь гласит: "Сохраняйся и предохраняйся", в том числе и для целостности. Интересно, а как же без Скуля все работали, архивировали, в том числе и работающие базы. И это еще когда о шедулере и не слыхивал никто, да и о Винде тоже.
2 - На первом месте. - Пока не подводила.
====
Ну ответь и ты на вопрос: ДБФ-ая база, работа круглосуточная (выгнать можно раз в неделю всех, не чаще), когда и как копироваться ?

(86) Большие базы на средних и крупных предприятиях надо хранить не на DBF (ибо потеря базы приведет к большим убыткам). Если все-таки DBF, то по любому полезно копировать базу (например, в обед или ночью).

(84,87) Есть понятие логическая транзакция - тоже самое что и во внутренем языке
НачатьТранзакцию(). Как это реализовывается на физическом уровне неважно.
Вот тебе пример без транзакции
До начала документ был непроведен, во время копирования база большая документ
записался непроведенным а движения к нему записались. Даже нет разрыва по транзакции. Плывут данные и отчеты.
Аналогичные разрывы могут быть по графам отбора.
Если же делать анализ файлов которые изменились после начала копирования - то сложность  такого копировщика очень возрастает и надежность его падает.

(90) >Если же делать анализ файлов которые изменились после начала копирования - то сложность  такого копировщика очень возрастает и надежность его падает.

Зацени прогу (45). Ничего сложного или ненадежного там нет. Цикл такой:
1) Считываю названия и время файлов в ТЗ
2) Копирую файлы
3) Проверяю, не изменилось ли время файлов. Если да, то для измененных файлов переход к пункту 1

(83)База копируется. При этом нельзя: создать новый документ, проводить или перезаписывать существующие. Справочники и константы изменять можно. Насколько я понял, проблема именно в том, чтобы не было критических ошибок связанных с документами, а их и не будет, т.к. ничего с ними сделать нельзя. В чём я не прав?

(89) См 28.
Есть два сервера.Осноной и резервный.
Базу делаем УРБД во второй базе никто не работает.
В шедулере обмен УРБД раз в час.
Если полетел или основной сервер или база данных на основном сервер, тогда
есть скрипт (уже написан) который переключит базу у всех пользователей на резервный сервер. Делай копии со свободной резервной переф базы когда хочешь.
Скрипт при необходимости сможет запустить любой пользователь если в этот
момент не будет меня или администратора (что тоже маловероятно).
Максимальная потеря данных базы 1 час ( можно поставить и полчаса)
Востановление работоспособности фирмы при аварии основного сервера 10 минут.

(92) ... "Проверяю, не изменилось ли время файлов. Если да, то для измененных файлов переход к пункту 1 "


  Кстати, всегда отключаю эту возможность в серверной ОС... Ибо при интенсивной работе торможение достигает 5% в некоторых случаях...


  А теперь ответь на один вопрос - если я создам в справочнике 100 элементов, удалю их через удаление помеченных и создам снова 10 элементов - изменится ли размер файла справочника?

ответ или сейчас (минут 10) или вечером... ухожу на работу...

(92) Ты что издеваешься (я тоже умею писать программы).
Ну и предвставь ситуацию я пользуюсь твоей программой копирования, летит основная база из копии полноценной версии  я поднять из-за бага в твоей программе не смогу и что я скажу своему руководство что я хороший, а во
всем виноват romix ?
Ответь лучше на мои вопросы и все встанет на свои места.
И еще будешь ли ты использовать subj если отвечаешь за базу головой ?

+92 Вот этот же цикл на языке 1С:
   //Дозаписываем файлы, если с момента архивации они изменялись
   
   ок=0;
   Пока ок=0 Цикл
       
       ок=1;
   
       т.ВыбратьСтроки();
       Пока т.ПолучитьСтроку()=1 Цикл
           имяф=т.Имя;
           фс.АтрибутыФайла(Откуда+"\"+ИмяФ,РазмерФайла,АтрибутыФайла,ВремяСоздания,ВремяПоследнегоДоступа,ВремяПоследнейЗаписи,РасширенноеИмяФайла);
           Если СокрЛП(т.Время)<>СокрЛП(ВремяПоследнейЗаписи) Тогда
               Сообщ1("Не совпадает файл: "+имяф);;
               т.Время=СокрЛП(ВремяПоследнейЗаписи);
               фс.КопироватьФайл(Откуда+"\"+имяф, Куда+"\"+имяф, 0);
               ок=0;
           Иначе    
               Состояние("Файл ок: "+имяф);;
           КонецЕсли;
       КонецЦикла;
   КонецЦикла;

(94) А если отвлечься от УРБД (и 1С) ?
Кстати, если уж копировать, то сразу видно - ни разу ты по серьезному не влетал. Для такого случая другой сервер должен находится в другой комнате, как минимум (на случай пожара). А исходя из буржуйских требований по АйТи безопасности теперь (после падения ихних башен 11 сентября) - то и в другом городе. Вот и выбирай - или компромис или защита по максимуму. Только кто захочет тратиться на защиту по максимуму.

(95) размер файла не измениться для dbf базы

(95) Размер проверять безусловно не надо (он может не измениться). А вот дату и время файла - надо (5% этого имхо стоят).

(98) верно

(96) Исходник открыт. Затачивай любой код под себя (или вообще не юзай его), и все будет хорошо.

(+102) На какой из вопросов я не ответил в (84)?

(83) Твой метод конечно будет работать и вероятность его правильной работы очень большая но учти при проведении документа мы опееррируем Логической транзакцией и я лично не знаю как для dbf версии отображается логическая транзакция на физическую ( до уровня фафлов lnk и специальных таблиц) - и налететь на грабли из-за этого незнания я не хочу.

сокращение времени проведения в условиях интенсивной работы на 5% - это весьма и весьма существенно...

Именно поэтому рекомендация убрать фиксацию даты и времени последнего изменения есть ВО ВСЕХ книжках...


для Мульки (хе-хе, тож 98) .... Читать надо книжки... по требованиям к копированию.... и хранению копий...

штатовский стандарт на хранение копий ... тридцатилетней давности... предусматривает хранение минимум 2-х копий... в разных зданиях ... причем требования к помещениям там якуею...

Так что 11 сентября здесь ни при чем... Это действовало еще 30 лет назад...

(97) Твой  алгоритм не выдерживает никакой критики. (два бала)
1с объект ФС работает очень сомнительно. Он даже не возвращает успешно или неуспешно скопирован файл.

(105) Тогда надо верификацию проводить посимвольным сравнением файлов. Т.е. ускорив на 5% одно, замедлим другое. +я не знаю как в 1С это сделать: ВК что ли писать... Или через fc...

(103) Ни на один.
Ответь хотя бы на
"В заключение хотелось бы услышать хоть одно разумное обоснование subj" -
именно обоснование а не техническую реализацию копирования,
учитывая что есть решение 94

(106) ниже я проверяю правильность копии. При несовпадении аварийно отваливаюсь. Так что не суди по всему алгоритму по его фрагменту.

(105) И кто следовал инструкциям 30-ти летней давности, тем более у нас ? Буржуи только и следовали - хранили архивы в разных зданиях, а тут на тебе - обе упали практически одновременно - а там тысячи компаний были - где теперь их базы/копии/архивы ?

(106) Как проверяешь поблочно или по атрибутам файла через объект ФС.
Если поблочно то и получишь что я говорил супернавороченую программу-поделку
копирования с высокой стоимостью этой программы с ее сомнительной надежностью - выборка то маленькая по ее тестированию и низкой целесообразностью.
На мои вопросы опять не ответил.

(108) Зачем - бери и юзай. Вот и все обоснование. Если возможны неточности при копировании, объясни, в какой момент это может произойти (если копия базы на 100% согласована).

УРБД - тоже решение.

SQL - самое правильное решение (если 1С плохо, как утв. Пит, работает в SQL, и легальная версия SQL слишком дорогая, то это имхо проблема 1С).

111 относиться к 109

(111) Скачай файл (26К) и посмотри. Проверяю длину исходного и скопированного файла. Если не совпадают, то ошибка. Если предложишь другой метод верификации (например, запуском программы FC), то милости прошу. Критикуй лучше свое отсутствие бэкапа, а не любое решение (тем более, что копия 100% согласована).

у меня база под 800 метров(1.4xeon+терминал+дбф), пакуется WinRAR-ом, без предварительного копирования 2 раза в день(ночью и в обед),ночью приоретет NORMAL,а в обед IDLE, пока все ОК, а тут оказывается не все так просто.
Есть у кого-нидь ещё варианты для автоматического архивирования БД
ИЛИ надо УРБД ставить,как сказал (2)?

(112) - легко Win Api write() возвращает успешно количество скопированых байтов,
при этом в _Errno содержится флаг ошибки (если она есть)
Также ошибки могут возникнуть и при закрытии файла.
ФС.КопироватьФайл() должна быть по идее не процедурой а функцией чтобы возвращать успешен или нет результат копирования ( о чем я года четыре назад писал на линию консультаций).
Можешь легко проверить работу этой функции берешь огромный файл начинаешь копировать его на сетевой диск методом ФС.КопироватьФайл().
Во время копирования закрой доступ к сетевой папке в которую копируешь файл.
(112) не подменяй subj.Лучше обоснуй subj. Ответов на мои вопросы я наверное от тебя не дождусь.

114. А может пора прекратить водить занос народ и толкать свои "поделки", не понимая ни сути того, что творишь и не особо слушая собесеников.
Вроде в ветке тебе уже ВСЕ втолковали, ан никак не уймешься.

(114) Где ты видел что у меня нет резервного копирования.
Я только утверждаю что как в subj делать нельзя.
От тебя нет обоснования subj - а все какие-то ненужные технические детали.
Вот мои решение
Первое в 94.
Второе решение. Расшариваем папку. Делаем копию.Зашариваем папку. Копию архивируем. Все это через скрипт можно поставить в планировщик.

(116) Еще можно, наверное, через WShell.Script. Обосновывать или отвечать на вопросы лучше от обратного: скажи, что в дополнение к уже сделанному ты от меня хочешь? База копируется по такому алгоритму 100% корректно, что еще надо?
(117) У Гендальфа разве не так копирование работает? У них "поделка"? Критикуй, повторюсь, свое отсутствие бэкапа.

(118) >Я только утверждаю что как в subj делать нельзя.
Даже с докопированием изменений?

Про второе решение я не понял. Какую папку зашариваем-расшариваем? Подробнее можно?

(119) Если у тебя все работает и ошибок не возникает и у тебя все правильно это твои проблемы. ( как говорит pit приготовь ведро вазелина и поставь свечку)
Но не надо плохих советов давать другим.
Своим бухам  когда они мне говорят при неправильной схеме - но ведь все работает. Я им отвечаю - оставте на каждом колесе по одному болту ведь машина же ездить будет - давайте съэкономим  на болтах.
(120) Сетевую папку где база dbf. ( и после этого ты еще со мной споришь :))) )

(121) Эксперт, блин. Тогда скажи, чем копия базы, сделанная по такой схеме (45), будет отличаться от правильной. Если не можешь сказать, то не ...

Если советуешь на базе с 3-4 пользователей юзать УРБД для бэкапа, то советуй дальше.

(121-2) Все равно не понятно. Зачем зашаривать - расшаривать? Если она и так расшарена. Чтобы юзера аварийно отвалились? Желаю успеха.

(122) Переходишь на личности.
Элементарные вещи даже не хочу объяснять.
3-4 пользователя не работают круглосуточно. в 94 речь идет со всем о другом.

(123) Не хочешь объяснять - не надо. А критиковать чужую прогу (ничего не объясняя) ты хочешь? Ну критикуй дальше. Заодно Хранитель Гендальфа покритикуй (он работает точно так же - т.е. докопирует измененные файлы)...

Дамы и господа! Прошу объяснить что такое УРБД (94), шедулер (94), УРИБ (28), МОД (28), и как это работает. В принципе возможно, что (94) вариант для нас оптимален, и можно даже без переключения между серверами в случае аварии.
На счет 100% надежности или 90%. Когда идет речь о том, что у вас или улетает вся база, или остается хоть какая-то копия (битая или лучше целая), я, считаю, что все выберут второе. Тем более если дневную базу данных, как у нас, когда идет постоянный поток входящего и исходящего товара, физически практически не возможно восстановить.

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