Главная проблема - создание копий файловой базы при работающих пользователях. Какого-то расписания нет, бухи порой и по ночам работают, и рано утром. Я пробовал Effector Saver, он выкидывает пользователей и делает копию, но частенько создает файлик блокировки cdn, потом его надо удалять вручную, чтобы базу можно было запустить, неудобно. У других программ копия при работающих пользователях либо не делается вообще, либо делается грязная. Есть ли вообще такой софт, позволяющий создавать нормальную копию файловой базы при работающих пользователях? Т.е. программа должна блокировать базу от изменений на время создания архива, либо выкидывать их.
Про возможности SQL знаю, но пока еще на него не перешли (необходимо финансирование дополнительное), может к НГ, не раньше.

Советую все таки подготовить бухов к тому,что в такое то время будет делаться копирование по настойчивее будьте, вы же программист BBDragon, а не менеджер:)
https://ru.wikipedia.org/wiki/Список_ПО_для_резервного_копирования
выбирайте любой.
Для себя определил, так делаю батник в котором убиваю процесс, резерв с помощью nnbackup и включить базу снова. На все про все 30 мин. Не умрут.

(1) Да, я обычно ставил копирование на 4-5 утра, но из-за отчетного периода им порой и в это время приходится работать. Тут уж лишь бы успеть все внести и проверить, что поделаешь.
А можно ваш батник глянуть? И как вы потом базу включаете?

(0) > Есть ли вообще такой софт, позволяющий создавать нормальную копию файловой базы при работающих пользователях? Т.е. программа должна блокировать базу от изменений на время создания архива, либо выкидывать их.

Нет. Кроме самой 1С, никто не может "блокировать базу от изменений". А 1С не может это сделать в файловой версии, поскольку нет выделенного сервера.

В общем, копите на SQL, другого выхода нет.

(0) грят команды copy,xcopy помогают

http://catalog.mista.ru/public/63970/

(4) они блокируют пользователей? О_о

(0) я встречал такие архивы, которые на горячую делали... из 10 архивов 2 стабильно битые...

советую копить на минисервер 1с, аж 14 тыщь рублей!!! говорят сейчас на такую сумму льготную ипотеку дают :)

(7) Я видел базы, где скульные файлы акронисом копировали....

(7) А скл? а клиентские лицензии?

Я на серверах EffectorSaver3 ставлю. В настройках запускаю как службу. Много настроек. Есть бесплатный. Для скуля лучше платный брать. Цену не помню, но недорогой совсем.

(9) PostgreSQL
клиентские лицензию у них вроде как есть, сейчас же работаю в файловом варианте

Основных вариантов резервного копирования файловых баз видится три:
1) запускать скрипт бекапа, который убивает процессы пользователей и архивирует папки с базами;
2) использовать утилиты типа vssadmin или cobianbackup, то есть shadowcopy;
3) делать РБД и копировать не саму базу, а ее реплику.

(8) скульную базу можно и акрониксом, скуль автоматом откатит незавершенные транзакции, а вот 1cd хренушки откатит, особенно если копия делается в момент записи ROOT блоков и таблиц размещения, тогда не просто пару проводок пропадают а весь файл становится нерабочим, и восстановлению не подлежит...

(13) "скульную базу можно и акрониксом"
Я тебя на работу сисадмином не приму...

(0)А зачем какой то софт?
Все прекрасно делается штатными средствами винды.
Используй графический интерфейс настройки теневого копирования, или vssadmin, или вот так - http://habrahabr.ru/post/246743/

И никаких проблем с работой пользователей. Во время создания теневой копии принудительно сбрасываются все кэши на диск.
А уж архивы для длительного хранения делаешь из уже созданной теневой копии.

То же самое умеет и акронис в принципе.

(6) Ерундой не надо на файловой страдать, выкидываются пользователи - делается копия, все в батнике.

Большое спасибо всем! Буду пробовать теневое копирование, как советует Jump)

(12) (15) (17) Теневые копии сами по себе не гарантируют целостность базы. Только защищают от самых страшных ошибок типа (13).

(17)Зря.

(18) Да абсолютной гарантии нет.
Но для файловой базы этот  метод не менее надежен, чем архивирование скульных баз средствами скуля.

(19) Обоснуй.

(17) Однозначно зря.Просто ты плохой администратор.Ну кто там в файловой в 5 утра пашет?Тот кто не выходил из базы с позавчера))Пистоны надо научиться вставлять.

(22) Зачем вставлять пистоны и доставлять неудобства пользователям? Когда можно просто сделать резервную копию?

(23) Опыт сын ошибок трудных.Надежность прежде всего.

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

(0) не парься, 7zip-ом пакуй, через батник, имя файла сделай типа версия_дата.7z: 08-03-06-1999_2015-10-26.7z.

(24)Теневое копирование это надежно.
(25)А вот это зря. dt это не для архивации, не факт что загрузится.
(26) Чем поможет? Все равно придется пользователей выгонять.

(27) говорят, 8.3.7 будет проверять корректность dt при выгрузке, или пытаться что-ли..

(28) Ну говорить можно много и долго, как сделают, посмотрим.

(12) > 2) использовать утилиты типа vssadmin или cobianbackup, то есть shadowcopy;
/
кто бы еще рассказал вменяемо, как работает это теневое копирование...

"Служба "Теневое копирование тома" (Volume Shadow Copy Service, VSS) сохраняет точки восстановления и поддерживает резервирование и восстановление файлов на основании механизма получения моментальных снимков файлов и данных (snapshot), именуемые теневыми копиями. VSS создаёт статические копии открытых файлов и приложений, которые при других обстоятельствах являются слишком непостоянными для резервирования."
.
хоть убейся я не понимаю, как можно создать "моментальный снимок" и что вообще под этим термином понимается

(12) У меня cobianbackup - рабочие файловые базы на 7.7 не копирует под win XP, правда пробовал 1.5 года назад.
Что - то поменялось ?

(31) вот как я понимаю моментальный снимок при теневом копировании

попробую крайне упростить

1. есть текстовый файл, который может состоять всего лишь из 3 букв, пусть изначально это будут буквы "АБВ"
2. при этом с этим файлом активно может работать приложение "Редактор", меняющее любые из этих 3 букв
3. архиватор просит систему создать моментальный снимок этого файла при помощи механизма теневого копирования
4. система отмечает этот момент запроса как начало создание снимка файла (то есть просто полной его копии)
5. но файл очень большой (целых 3 буквы) и его чтение занимает целых полторы минуты (по 30 секунд на букву)
6. система прочитывает и пишет в копию первую букву файла (А)
7. в следующий момент редактор просит систему записать вместо третей буквы (В) букву (Х)
8. система пишет в третью позицию файла букву Х, но отмечает в своих записях, что на момент начала теневого копирования в  этой позиции была буква (В)
9. система прочитывает и пишет в копию вторую букву файла (Б)
10. система доходит до третей буквы файла (теперь уже там стоит Х), но по своим записям определяет, что она была изменена с момента начала снимка и из своих записей берёт для копии первоначальную букву (В)

таким образом несмотря на то, что в момент создания снимка файл был изменен в третей букве (В на Х) в копию попали изначальные АБВ, а не АБХ

уффф, получилось как-то не очень, буду рад, если меня поправят более знающие товарищи

(21)Я не верю, что пользователи колотят сутками и не отвлекаются от базы. Простой организационный регламент, что база будет недоступна в 5 часов на 15-20 минут обеспечит надёжное архивирование без лукавых прыжков и ужимок. Лучше за эти 15-20 минут сходят в туалет. Надежность важнее непрерывности.

Штатно, через планировщик задач, в три этапа.
1 установка блокировки.
2 минут через 5 делаем архив
3 минут через ... снимаем блокировку

никаких проблем более трёх лет

(33) В принципе идея передана верно. Поправлю только, что
1) снимок создается не файла, а всего тома;
2) п. 6, 9, 10 происходят не сразу, а по мере чтения файла архиватором; п. 4 происходит быстро.

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

Чтобы такого не происходило, п. 4 должен быть согласован с приложением. Приложение может реализовать специальный компонент (VSS Writer), который будет получать уведомления о событиях п. 3-4 (и некоторых других) и сможет  их как-то обработать. А именно, привести все свои открытые файлы в согласованное состояние на момент снимка.

У SQL Server такой VSS writer есть, его видно в службах. Для файловой же 1С и это сделать невозможно, так как запись в базу происходит с клиентов, а не централизованно. (Теоретически, это можно сделать для терминальной работы, если других не пускать).

Поэтому (18) .

(27) теневое копирование для СУБД - зло, оно делает "моментальный снимок" файла, теперь представь снимок посреди проведения документа, старые движения удалились а новые не забекапились... информации о том, что идет транзакция в 1сд не хранится... откатить невозможно...

а теперь более сложный вариант, снимок на момент реструктуризации:

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

но есть и вариант когда наступит полный швах базы...

теневое копирование замечательно работает с данными где нет транзакционных действий или имеется механизм отката (как например в скуле) но с 1сд или например мдб это ОЧЕНЬ плохой вариант

(34) Сутками могут колотить регламенты и обмены. Но в файловой, конечно, вряд ли. :)

(36)почти одно и тоже написал :)

(39) :)

(33) Не так.
Во первых теневое копирование должно поддерживаться файловой системой.

И происходит оно так -
1)поступает команда подготовки к созданию теневой копии.
2)система принудительно сбрасывает все кэшированные данные на диск.
3)Запись во все существующие файлы  ПОЛНОСТЬЮ блокируется!!!
Это и есть создание теневой копии - все файлы которые были на томе получили запрет на изменение.
4)Вся запись которая поступает после создания теневой копии, пишется в дополнительные файлы, связанные с основными.
Т.е работа с диском продолжается, но все файлы которые существовали на диске в момент создания копии не изменяются.
Далее система аккуратно копирует "замороженные" файлы в хранилище.

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

(37) Не следует считать что в файловом варианте совсем нет поддержки транзакций.
Он есть, и реализуется самой платформой. Но он более простой нежели в нормальных СУБД.

(41) 3), 4) - неверно. Почитай матчасть еще раз.

(4) + Еще robocopy)

(43)Могу вам посоветовать то же самое.
Я все верно изложил.
Учите принципы работы файловых систем.

Даже если забыть про теневое копирование, и просто посмотреть как работает запись в файловой системе -
У вас есть файл в котором содержится текст "ВАСЯ", он записан на диск в ячейки с номерами 1234.
Т.е на диске это будет выглядеть так-
1-В
2-А
3-С
4-Я
Допустим вы открыли этот файл и изменили букву "С" на букву "В" и получилось "ВАЛЯ"
В файловой системе появляется запись, что "ВАЛЯ" записано в ячейки 1254
Т.е на диске это будет выглядеть так-
1-В
2-А
3-С
4-Я
5-Л

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

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

+ (45) Поправочка- "и изменили букву "С" на букву "В" " читать как "и изменили букву "С" на букву "Л" "

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

А при теневом копированиии - она будет иметь ссылку из теневой копии. И не может быть затерта.

Вот и весь фокус, и ничего сложного.

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

И по этому принципу работает любая база данных, а файловая система, это частный случай базы данных.

(45) Причем тут обычная запись, если разговор про теневые копии? Кстати, принцип записи зависит от файловой системы. Такой, как ты описал, тоже встречается в некоторых (не в NTFS).

А про теневые копии почитай тут, все хорошо расписано: https://technet.microsoft.com/en-us/library/cc785914(WS.10).aspx

Соглашусь с (36).
VSS должен поддерживаться приложением, у всех серверов баз данных есть writer's
Other components that are involved in the snapshot creation process are writers. The aim of Shadow Copy is to create consistent reliable snapshots. But sometimes, this cannot simply be achieved by completing all pending file change operations. Sometimes, it is necessary to complete a series of inter-related changes to several related files. For example, when a database application transfers a piece of data from one file to another, it needs to delete it from the source file and create it in the destination file. Hence, a snapshot must not be between the first deletion and the subsequent creation, or else it is worthless; it must either be before the deletion or after the creation. Enforcing this semantic consistency is the duty of writers.
Сами переводите ))

(37) недавно выявил, что операции "wbadmin start backup" отлавливает mssql и хранить в истории своих бэкапов... но все равно mssql нужно бэкапить родными средствами.

(0) cobian backup использую.
а кто подскажет бекапер с функцией отправки в облако (dbox, ядиск, гуглдиск)? само собой для 1СникаЮ то есть бесплатный.

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

Т.е запись на жесткий диск во время создания теневой копии не прерывается.

А принцип записи он один для всех файловых систем и БД.
Просто такой принцип записи создает кучу мусора и сильную фрагментацию, поэтому с ним стараются бороться.
Либо оптимизируя файловую систему, либо запуская сборку мусора(сжатие и оптимизация) для БД.

(51) Данные SQL базы храняться в СУБД которая называется mssql.
И бэкапить их надо штатными методами, т.е методами mssql.

Данные файловой базы хранятся в СУБД которая называется файловая система.
И бэкапить их надо штатными методами, т.е методами файловой системы.

(33) дырка в рассуждениях:
"8. система пишет в третью позицию файла букву Х, но отмечает в своих записях, что на момент начала теневого копирования в  этой позиции была буква (В) "
- откуда система знает что на момент начала теневого копирования в этой позиции была буква Б?
..?
при записи на третью позицию буквы Х система знает что она находится в состоянии "теневого копирования" данного файла - и перед записью буквы Х - читает букву Б, скидывает в теневую копию и только после этого пишет букву Х...?
.
при таком варианте активная работа с файлоам/файлами при теневом копировании будет существенно замедляться..? и каким образом получается тогда "мгновенный снимок"..? или под "мгновенным снимком" понимается возможность создания пусть и продолжительного по времени, но состояния файла, соответсвующего времени старта "теневого "копирования"?
.

(36) "1) снимок создается не файла, а всего тома; " -ээээ? это как..? мне надо создать актуальный бэкап файловой базы из кучи файликов (общий размер ну допусти 5Гб), (условно) "натравливаю" на папку с базой "теневое копирование" - и в теневую копию пойдет весь том? (400ГБ) - то есть вместе с тем что попросил в теневую копию пойдут еще куча записей всяких файлов, с которыми система работает на этом же диске/томе?

(55)Там вообще полностью неверно описан принцип работы.

(56)Теневое копирование возможно только для тома, это уровень файловой системы. Но никак не для одного файла.

"в теневую копию пойдет весь том? (400ГБ)"
И да и нет.

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

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

(58) спасибо за разъяснения

(58) непонятно!
(58) "Но вес теневой копии будет очень маленьким. " - почему? потому что по сути вес теневой копии будет "равен" количеству записи после окончания теневой копии..?

Пока что непонятно.
теневая копия обеспечивает целостность если попала на проведение транзакции..?

ссылка - https://technet.microsoft.com/en-us/library/cc785914(WS.10).aspx - конечно хорошо, но хотелось бы что-то по русски - боюсь не уловлю нюансы..

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

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

(62) Довольно сложный момент.
Она обеспечивает целостность на уровне файловой системы.
Т.е "битый" файл получить в результате теневой копии нереально.
Но файловая система ничего не знает о транзакциях данных.
И тут уже все зависит от того насколько корректно приложение работает с файлом, насколько защищено от логических сбоев.
В общем это уже дело платформы 1с.

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

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

(64) это как так не происходит перемещения данных (архиватор со 100% сжатием???) ? имеем два варианта файла? который лежит в теневой копии и новый (который получился как раз тогда когда шла теневая копия) - они что В ОДНОМ МЕСТЕ ЛЕЖАТ? полностью всЁ до байтика? нет я думаю - различия же есть - значит по сути "перемещение" данных прошло..? или я совсем тупой?

(66)Что такое файл, для файловой системы?
Это просто набор ссылок на сектора диска, содержащие информацию.

Поэтому после создания теневой копии мы имеем два набора ссылок - один вариант на момент теневой копии, другой текущий.
А данные то физически с диска никто не перемещал.

Т.е небольшое перемещение данных есть - но это перемещение изменений.

(67) ну да, я это так и думал.
спсб

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

(67) В линуксовой файловой системе btrfs еще круче - там все снапшоты равноправны и доступны на запись.

(70)Возможно. Не ковырял btrfs.
А какой практический смысл в доступности снапшота на запись?

Бухгалтера работают в 4-5 утра!? А чем они днем занимаются?
Это не бухгалтера, а операторы ввода данных, притом очень и очень некомпетентные.

(72)Что в этом удивительного?
У одного моего клиента это штатная ситуация.
Есть несколько бухгалтеров которые сидят в офисе с 9 до 6.
Есть несколько бухгалтеров которые работают удаленно, из дома, и зачастую допоздна или рано утром.
Какая разница когда делается работа? главное чтобы она была сделана.

А в отчетный период, так вообще аврал и круглосуточный режим работы.


"Это не бухгалтера, а операторы ввода данных, притом очень и очень некомпетентные."  - обоснуйте.

(71) Ну например - поиграться с базой "а что будет если", не тратя времени на полное копирование)

(74) Ну играться с рабочей базой не лучшая идея при любом раскладе.
А если база не рабочая - это позволяет и теневое копирование.
Попробовал, не понравилось - откатил.

(61) (66) Используется принцип copy-on-write, то есть копирование при записи. Единицей отслеживания изменений является кластер файловой системы (а не сектор диска).
Когда после создания теневой копии 1С (или другое приложение) дает ОС команду записать в файл n байт по такому-то адресу, ОС транслирует это в конкретный набор из m кластеров, занимаемых этим файлом. Пержнее содержимое этих кластеров пишется в теневую копию (вместе с их адресами). Затем в них пишется новые данные, как при обычной записи.

В результате объем теневой копии равен объему изменений. Но содержатся там старые данные, а не новые (здесь  Jump описал неверно).

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