[@romsan]

Доброго дня всем.
Нет профессиональных знаний в области 1С, а проблему решать надо. Иначе придет пушной зверек.
УТ 10.3 (писанная), файловая. Для реализации ежедневных архивов в течении 3-х лет использовалась программа Effector Saver 3 С помощью данной проги, делалось ежедневное тестирование и исправление и собственно сам BackUp по ночам. Среднее время тестирования составляла около 2-х часов. Архивирование - 15 минут.
C 21 числа перестал формироваться BackUp. Начал смотреть логи.... прога EF Saver 3 запускает задачу в 01-00 и.... всё зависает до утра. Утром пользователи не могут зайти в БД, т.к. она изолирована (прога для своих нужд средствами 1С завершает работу пользунов (если таковые остались), блокирует доступ к БД, делает свои дела, а после разрешает доступ к БД)
Я уже 3-й день по утрам захожу на Терм. сервер и отменяю "зависшую" задачу.
Сперва я предположил, что прога Ef saver глюкнула (не буду скрывать - ломанная), однако сегодня утром в 06-00 я зашел удаленно с дома на терм сервер и запустил выгрузку информационной базы через конфигуратор. Попав на работу в 8-00 задача завершена не была. Просто ничего не происходит, 1С висит (не отвечает). Пользуны в БД попасть не могут. "Жестко" вырубил процесс 1С через диспетчер задач. Пользуны зашли в БД... работа пошла. В течении рабочего дня мне нужно найти решение, что предпринять.

Прошу знающих дать рекомендации, что предпринять в данной ситуации.

[@Phil]

Внесу ещё 5 своих копеек по поводу копирования и бэкапов

С начало приведу рекомендации от самой 1с

Файловый вариант информационной базы

Создание резервной копии в клиент-серверном варианте

Выгрузка информационной базы данных в файл

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

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

[@romsan]

НО перед началом копирования не должно быть ни одного соединения с базой, даже конфигуратор необходимо закрыть, т.к. можем получить неактуальную информацию, или просто битую базу.
Сам неоднократно наступал на жти грабли при копирования CD файла на "горячую".

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

[@Volexovich]

1. Сделать копию.
Все последующие действия строго с копией!
2. Запустить chdbfl.exe (в папке с исполняемыми файлами 1с)
3. Если ошибок нет, то уже в конфигураторе тестирование и исправление.
Почему в таком порядке, потому что надо быстро выявить проблему и действия выполняются с копией. По практите тестировани в конфигураторе может зависнуть или занять очень много времени, кроме того могут не выявиться повреждения в физической структуре.
chdbfl - сразу выявит повреждения в структуре и попробует починить БД. Да, бывает он убивает БД, по этому работать обязательно с КОПИЕЙ!

[@romsan]

1. Сделать копию.
Все последующие действия строго с копией!
2. Запустить chdbfl.exe (в папке с исполняемыми файлами 1с)
3. Если ошибок нет, то уже в конфигураторе тестирование и исправление.

сегодня вечером попробуем. Отпишусь....

[@romsan]

1) Скопировал полностью каталог рабочей БД на системный SSD
2) Запустил chdbfl.exe, выбрал файл в скопированной папке
3) Сразу же окно побелело и, в ДЗ, "не отвечает" Однако счетчик памяти тикает в сторону увеличения понемногу. Ждемс.....

Кликните здесь для просмотра всего текста

а, собственно значение 111 506 345 122 байт прочитано.... это что, 111 Гигов? Откуда?

[@romsan]

так. Появился таки результат.

Кликните здесь для просмотра всего текста

[@romsan]

Во блин!

Кликните здесь для просмотра всего текста

это как понимать?

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

[@romsan]

Зашел в конфигуратор, запустил выгрузку... через примерно минут 15 база выгрузилась.
Вобщем подменяю каталоги с БД.
Всем спасибо.

[@Dethmontt]

romsan, воткни пока батник в планировщик заданий на копирование фала .cd

[@romsan]

Effector saver отработал норм. (ТИ заняло 1:10 времени, выгрузка - 5 минут)

воткни пока батник в планировщик заданий на копирование фала .cd

Т.е. настроить через effector saver Завершение работы пользователей средствами 1С, а потом robocopy кидать в др. каталог ТОЛЬКО 1Сv8.1cd ? Дублирующий BackUp ?

[@Dethmontt]

Т.е. настроить через effector saver Завершение работы пользователей средствами 1С

А зачем делать завершение работы пользователей?

robocopy кидать в др. каталог ТОЛЬКО 1Сv8.1cd ? Дублирующий BackUp ?

Пока не разберешься что случилось с БД, просто копируй файл 1Сv8.1cd.

[@romsan]

А зачем делать завершение работы пользователей?

ну как зачем!? Вон, выше чел написал же опасения:

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

Сейчас у меня всё норм с базой. Продолжается выполнение ТиИ БД, потом выгрузка *.dt, потом планировщиком монтируется внешний диск (шара на ПК2), переноситься сформированная *.dt на тот ПК. Отсутствие файла сигнализируется на мыло. Шара размонтировывается), и, на том ПК2 еще стоит Handy Backup, который запускает синхронизацию с облаком.
В 3-х местах лежит архив. Печальный опыт ловли виря Vault в 2014 году заставляет городить двойной, а то и тройной этап копирования важных данных.

[@Dethmontt]

romsan, 10 лет копирую - полет нормальный...

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

Добавлено через 10 минут
БОЛЬШАЯ вероятность получить ОШИБКУ при разворачивании бакапа из dt файла (на практике - очень частая), т.к. не только структура метаданных может препятствовать, но и сами сохраненные данные...
Поэтому 1С и рекомендует делать копию CD файла, т.к. ее хотя бы отремонтировать можно))

[@romsan]

БОЛЬШАЯ вероятность получить ОШИБКУ при разворачивании бакапа из dt файла (на практике - очень частая),

хоть и не часто, я бы сказал, даже редко, но восстановление БД из *.dt никогда не вызывало проблем. Во всяком случае за мои 3 года контроля за данной БД. Но, приму к сведению, Ваши рекомендации. Наваять *.bat-ник с командами копирования и в cron его запихнуть на выполнение перед выгрузкой *.dt (хотя можно и в самом Effector Saver это прописать) труда не составит.
Огромное спасибо всем за поддержку, разъяснения и подсказки. Будут проблемы с сетями - обращайтесь

[@Volexovich]

Я бы рекомендовал после chdbfl прогнать тестирование через конфигуратор ибо выдыхать полностью еще рано.

[@romsan]

Я бы рекомендовал после chdbfl прогнать тестирование через конфигуратор

это сделано в первую же ночь.
Вот результат:

Кликните здесь для просмотра всего текста