Восстановление удаленной информации в базе 1С 8.2 на SQL

Предыстория.

Организация ведет бухгалтерский учет в корпоративной базе по нескольким организациям в типовой 1С 8.2 БП КОРП на SQL 2008. По ночам делаются бэкапы на ленточку. Утром очередного дня обнаружилось, что по нескольким организациям «поехала» отчетность, «краснота», нет документов и пр. В ходе оперативного анализа журнала регистрации выяснилось, что в ночь было запущено удаление документов по нескольким организациям, в частности «авансовых отчетов» (причину выводим за скобки). Ночной бэкап был сделан, пока шел процесс удаления документов, т.е. утром не оказалось полноценной копии базы, чтобы сделать восстановление штатными средствами.
Примечание: удаление документов выполнялось командой Удалить() без контроля ссылочной целостности.

Данная новость настигла меня, когда я был вдали от офиса, компьютера и интернета. Чуть позже я понял, что в этом был небольшой плюс для меня, т.к. не ощущал того, что в этот момент происходит в бухгалтерии, в службе ИТ и других подразделениях. Голова была холодной, что позволяло мыслить свободнее.

Варианты решений.

1. Первое и самое простое решение с технической точки зрения – это восстановить базу от предыдущей ночи. В этом случае пользователям придется повторить операции вчерашнего дня. Не смертельно, можно, но…

2. Восстановить базу из бэкапа от прошедшей ночи. Затем экспортом-импортом перенести недостающие документы из копии базы от предыдущей ночи. Можно, но… в этом случае придется перепроводить эти документы + восстанавливать последовательность по всем организациям. У нас это займет около месяца, а вчерашняя отчетность нужна сегодня (!).

3. Это решение – не простое, а, как оказалось, золотое... Восстановить базу из бэкапа от прошедшей ночи. Затем, зная структуру таблиц базы данных, экспортировать соответствующие данные средствами СУБД из копии базы от предыдущей ночи. Я только слышал, что иногда делают что-то подобное с 1С-овскими базами. Конечно, этот вариант нелегитимный, но у меня не оставалось другого выбора. Скажу честно, все делал в первый раз.

Процедура восстановления.

Через пару часов я добрался до компа и интернета. OpenVPN рулит. За это время сисадмин развернул копии баз от прошедшей и предыдущей ночи. Пришлось срочно искать внешнюю обработку, которая предоставляет информацию о структуре базы данных. Таковая была найдена на жестком диске (скачивал ранее с источника - //infostart.ru/public/16282/).

Обработка показала следующее. Данные по документу «авансовый отчет» хранятся в семи таблицах, в двух из них данных не было. Итого необходимо перенести информацию из пяти таблиц (отмечены цветом):

Запускаем SQL Management Studio. Команда INSERT в помощь. Т.к. на момент создания бэкапа данные были удалены частично, то пришлось предварительно удалить данные в таблицах-приемниках, чтобы при добавлении не было задвоений. Ура! Несколько тысяч документов с табличными частями «переехали» из базы-источника в базу приемник. «Простите, но где проводки?» - спросила бухгалтер. Мне казалось, что они останутся в базе после такого «жесткого» удаления документов. Возникшая ситуация напомнила мне вариант № 2.

Что там с проводками? Проводки хранятся в регистре бухгалтерии «Хозрасчетный». Структура оказалась следующая:

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

Пришлось использовать все туже команду INSERT, но с условием, что из базы-источника копируются записи только для документов, которые находятся в таблице документа «авансовый отчет» базы-приемника. Отбор по уникальному номеру не составил труда. Сначала были перенесены данные «основной» таблицы, затем таблицы со «значениями субконто». Переносить «итоги» я посчитал нецелесообразным.
«Документы и проводки есть, но отчетность все равно кривая» - сказала бухгалтер.
Время шло, позади полдня, все на нервах, просят выполнить вариант № 1.

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

В качестве заключения.

На все ушло часа три. Это притом, что все делалось впервые и на свой страх и риск.
Чуть позже обнаружилось, что отсутствуют «авансовые отчеты» в «журнале операций», но изложенным выше способом данные были скопированы в рабочую базу. Структура журнала документа «журнал операций» следующая:

Смею предположить, что аналогичное решение можно использовать и в других нештатных (!) ситуациях применительно к другим объектам. Надеюсь, у вас все будет хорошо и не придется заниматься подобным.

PS
Это моя первая публикация, поэтому не судите строго. Буду рад, если кому-нибудь пригодится изложенная идея. «Велосипед» - скажете? Ну, кому – как.
Если появятся вопросы по конкретике, то постараюсь дополнить в статье.