Здравствуйте!
База в файловом режиме. Работает круглосуточно. Хотим сделать архивацию 3 раза в сутки. Подскажите как в реальном времени можно архивировать базу 1С 8.2 ?

купить клиент-сервер

>База в файловом режиме. Работает круглосуточно

смелые люди

(0) Копируйте файл базы налету. Но всегда будет вероятность "битой копии".  Поэтому (1) :)

нормальный бэкап файловой - это копия 1cd, без работающих там людей

(0) средствами 1с не получится...только всякими сторонними теневыми копированиями и пр. но есть вариант получить неработоспособный архив
..но имхо (2) +1, т.е. перейти на клиент-серверный вариант и архивировать на более высоком уровне СУБД

(4) УРИБ?

(5) скуль, пострис и пр.)

(4) вообще то это более низкий уровень по терминологии, но я советую его

Если acronis-ом весь диск ?

(7) согласен) ошибся

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

+1 к (4)

Acronis делает без ошибок образ работающей системы, а 1С не сможет ?

(8) насколько загружена база ? - СУБД проследит чтобы архив был "корректным", т.е. с зафиксированными транзакциями; в случае копирования (даже акронисом) вы можете попасть в момент когда транзакция не завершилась...это же "снимок" данных с диска

Понял, значить только SQL.

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

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

(16) Делают....

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

(17) это особо одарённые видимо

(6) Зачем?
Я про УРИБ копию. Т.е. настроить обмен и обмениваться с копией, а копию уже бекапить

(20) можно и так))
...например видел и такое решение - чтобы получать именно 1с-кий архив в компании делали репликацию базы скулем и эту копию архивировали 1с-ом)))

(20) Можно через УРИБ. Только замучаетесь с обновлением и плн обмена надо делать свой, полностью полный.

(22)  а чем типовой полный обмен не нравится???

(23) Ну КЛАДР туда точно не входит :)

(24) господи, ну а кладр то зачем? Это же классификатор, и он не несёт никакой нагрузки с точки зрения учета. Он служит для помощи ввода НОВОГО адреса, а не просмотр старого

(25) база 24 часа в сутки работает - что плохого в совете перейти на ступеньку выше до клиент-серверного варианта ?))

При такой нагрузке переведем базу на клиент-сервер.

(8) Побоку, как и чем.... Все ровно при копировании всего раздела Диска, пользователи отвалятся из БД по таймеру

(17) Извращенец :)

(28) Если через ShadowCopy, то почему отвалятся-то? В моей конторе админ таким образом многогигабайтные виртуалки бэкапит и никто даже не замечает. Там же, по сущности, напшот файловой системы делается. Механизм, аналогичный работе бэкапов в SQL.

(30) Не долго админ проработает.
Оперативку кто будет бэкапить?
Тоже самое и с теневой копией базы. Проблема не скопировать то, что на диске. Проблема сохранить то, что в оперативной памяти.
Файловая базе это не базе на sql сервере. В ней нет журналирования. Транзакционная целостность держится на уровне файловой системы. Простой пример.
Пользователь открыл транзакцию на запись. На уровне файловой системы (допустим у нас журналируемая ФС) открылась транзакция. В этот момент делается теневая копия. База скопировалась при не закрытой транзакции. После этого идет закрытие транзакции на уровне ФС. Благо ФС позвоялет это сделать. И что мы получаем? Не полноценную базу.

http://efsaver.ru/

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