Утром случился казус, что-то сделали на подстанции, вырубило офис, вырубило бесперебойники соответственно вырубило сервера (погорели насосы в догонку), итак, база 1С 7.7 SQL основная, ушла в режим Suspect - это побороли, реанимации показали что и mdf и ldf с ошибками, база чекается с ошибками, ошибки не исправляются, база не выгружается, но запускается. Есть бэкап без вчерашнего дня, есть мысль восстановить из бэкапа и выгрузить вчерашний день из битой базы.
Вопрос, есть обработки универсальные по выгрузке из комплексной и загрузки в комплексную? Конфигурация сильно переделанная, новые виды документов и т.п.

1. Копируй всё, что осталось.
2. Поставь хорошие ИБП.
3. Бери бекап, бери mlg, бери распечатки, бери ответственного за случившееся.

выгрузка/загрузка из/в xml

но если данных много - то копать не перекопать еще.

а, это ж семерка

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

(0) есть типовая обмен между одинаковыми..укажешь период 1 день и все документы...делов то.. и выгрузишь в бэкап

(5) где ее найти?

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

Universam.ert погугли

Export771 - так называется она

(9) да такую нашел на диске ИТС, как она с не типовыми работает ?

(10) если я не ошибаюсь, то ей помойму всеровно типовая или нет, пробовал ее открыть у себя?

(0) Поищи ис "Перенос по ОЛЕ", точное название не помню.

Universam.ert работает с нетиповыми хорошо. пользовался много раз проблем нет.

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

Вопрос только - что именно переносить.
Как отбирать документы, которые заведены только в течении пропавшего дня? Новые еще можно по номеру определить (отсутствует в базе-приёмнике), а модифицированные старые?
А справочники? Те, что потянуться по ссылкам с документами сами обновятся, а как быть с теми элементами, которые вчера менялись пользователями, но в документах не участвовали?

Я бы ограничился переносом только очевидных и самых массовых операций. Чей перенос однозначен, прост и необходим (в силу массовости).
А всё остальное пусть пользователи ручками повторно вводят.

PS И даже после такого всё равно находятся люди, которые спрашивают для чего нужна полная модель восстановления на продуктивных базах и зачем делать регулярные инкрементальные бекапы. А вот именно для таких случаев. Проще потратиться на нормальный дисковый массив для хранения баз и бекапов, чем потом считать во сколько обойдётся день простоя всего персонала, который колотил данные в базу, а теперь будет ждать когда восстановят данные, а потом еще проверять их корректность и полноту, и трястись - не потерялось ли чего (какая-нибудь парочка отгрузок на пару сотен тысяч НДСа).

(15) Журнал регистрации никто не отменял. Если он цел то все находиться на раз.

(0) если доков немного то руками перезабейте с бумажек
Возни с восстановлением будет больше если какие то таблицы целиком накрылись

(17) да, так и сделаем, Export/Imort выдают ошибки, разбираться особо некогда с этим.

(0) Мой совет - нужно настраивать бесперебойник, чтобы он выключал компьютер при заданном уровне разряда батареи и снова подавал питание после его возобновления, также в биосе компа настроить включение при восстановлении питания. Плюс настройка сообщений на почту при событии если бесперебойник не проходит внутренний тест (а не когда серв упадет из за вышедшей из строя батареи), который он периодически должен делать (для примера бесперебойники APC). И вот после такого все вышеизложенное не понадобится, по крайней мере, при отключении электричества.

(0) Вот http://catalog.mista.ru/public/14022/
Пользуйся.

УРБД на базе было?
Если да, то:
1.развернуть бэкап
2. временно сделать восстановленую из бэкапа базу периферийкой
3. в аварийной базе пробежаться по журналу регистрации, записать все документы/справочники упомянутые во вчерашних событиях DocWrite/RefWrit в 1sUpdts
4. сделать обмен
5. восстановить базу центральной
делов на пол-часа, а то и меньше,  из которых дольше всего разворачивать базу из бэкапа

(0) база чекается с ошибками, ошибки не исправляются, (с)
Чекали чем ? только скулем ? или 1С-ом тоже ?

Хм. ради интереса, благо сегодня клюшки под рукой, попробовал вручную сделать распределенкой - получилось. так что если даже база была нераспределенной - делаешь следующее:
1. делаешь распределенной восстановленную из бэкапа.
2. EM'ом или SM'ом получаешь скрипты для создания таблиц УРБД, применяешь их в битой. ну и дальше - см (21)

(22) а смысл проверять 1Сом,  если хранилище с ошибками?

(24) смысл в том что разные способы - очищение ссылок и прочее ...

(25) какое может быть "очищение ссылок и прочее", если хранилище просто не даст никаких ссылок? все закончится на "проверке физической целостности"...

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

(0)
проще примитивным sql запросом проинсёртить таблички.

тип того

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

(27) И так ясно. Даже без запуска. там куска таблицы нет, а вы про "нечитаемый символ в таблице" :-)))

(16) > Журнал регистрации никто не отменял. Если он цел то все находиться на раз.

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

(32) именно. если учесть, что происшествие случилось "утром", а режим работы вряд ли 24/7, то скорее всего все восстановление могло бы пройти почти бескровно и почти незаметно...

но, как известно, "админы делятся на две категории - те, кто ЕЩЕ не делает бэкап, и те кто УЖЕ делает"