Как восстановить перезаписанную базу 1с
Как восстановить перезаписанную базу 1с
Использован релиз 3.0.104
Процесс восстановления копии информационной базы, созданной до начала процедуры свертки, зависит от формата файла, в котором она сохранена:
ВНИМАНИЕ! При восстановлении резервной копии информационной базы вся существующая информация будет замещена на информацию из файла загрузки. Восстановить замещенную информацию невозможно. Для восстановления копии обязательно создайте и подключите новую информационную базу (создайте новый каталог на вашем компьютере и по кнопке «Добавить» в окне запуска программы подключите новую информационную базу, указав путь к новому каталогу).
Рассмотрим восстановление копии информационной базы, созданной в рамках первого этапа свертки информационной базы:
Смотрите также
Случайно загрузил старую базу. Как вернуть?
(0) Всегда опасаясь подобного (загрузить не в ту базу), завел такую привычку:
При загрузки базы держать открытым только ОДИН конфигуратор, и перед загрузкой смотреть «о программе» чтобы убедиться, что база ТА.
Как у альпиниста: проверить инвентарь перед восхождением.
(31)Чтение по остаточному намагничиванию это сказки.
Т.е теоретически прочитать можно, но очень высок процент ошибки.
А теперь прикинь сколько времени и денег займет чтение базы по остаточному намагничиванию?
Нужна команда специалистов, год времени, спец оборудование и прочее. По деньгам это миллионы долларов.
Информация которая может содержаться в базе столько не стоит.
(37) «Как у альпиниста: проверить инвентарь перед восхождением. »
+
А то альпиниста, сорвавшегося со скалы тоже, наверное, можно «соскрести» от основания, и «восстановить». Но правильная «техника безопасности» должна быть такой, чтобы НЕ падать НИКОГДА.
А вы (мы), «работники IT» почему не думаете о подобной «технике безопасности». Не своё не жалко? Или просто пофигисты?
(25)Восстановить с SSD труднее, а не проще.
во первых HDD тоже пишет не в то место где лежало, а куда удобней записать в данный момент.
Во вторых SSD управляется собственным процессором со своей логикой, и где оказались данные предсказать очень трудно, надо полностью раскручивать таблицу соответствия LBA и реальных ячеек.
(45) Да, у меня тоже в папках с файловыми базами хранится «история» в виде: 1CD_1, 1CD_2, или 1CD_ПередЗагрузкой 🙂
(46)Разумеется есть.
Ничего фантастического там нет.
Просто это довольно тонкое оборудование не серийное и соответственно имеют его лишь единицы ведомств, а не коммерческие конторы по восстановлению
Ну и поскольку надежность такого восстановления далека от 100%, то при восстановлении не идет речи о восстановлении работспособности базы данных.
Выдернуть часть информации с вордовского документа это вполне реально.
А вот полностью восстановить работоспособность БД объемом несколько гигабайт это уже фантастика.
Спасает ситуацию лишь то что у каждого блока есть своя контрольная сумма.
Но даже с этим это сложный и трудоемкий процесс, не гарантироующий 100% результата.
И чем больше объем данных подлежащий восстановлению тем сложнее.
Восстановление базы 1С из бэкапа MS SQL
Модели восстановление базы данных в MS SQL существует две «простая» и «полная». Отличаются они тем, что в полной модели восстановления ведется еще и бэкап журнала транзакций. Рассмотрим восстановление базы 1С в MS SQL на примере простой модели восстановления.
Восстанавливаем полный бэкап.
В Microsoft SQL Server Managment Studio создаем базу данных в которую будет выполнятся восстановление. Как настроить базу в MS SQL для 1С рассмотренно здесь.
Выбираем источник восстановления «С устройства» и указываем путь к файлу бэкапа. После добавления файла бэкапа отмечаем галочкой набор данных для восстановления.
Слева в меню «Выбор страницы» переходим к пункту «Параметры». В пункте параметры восстановления отмечаем «Перезаписать существующую базу данных (WITH REPLACE)».
Если восстанавливаете только полный бэкап, то в разеде состояние восстановления оставляем пункт «Оставить базу готовой к использованию»
Если далее планируется восстанавливать еще и разностный бэкап, то в разеде состояние восстановления отмечаем «Оставить базу данных в неработающем состоянии. «.
Жмем ОК и дожидаемся сообщения о завершении восстановления.
Восстанавливаем разностный бэкап.
На странице Параметры настройки оставляем как есть. В разделе «Состояние восстановления» отмечен пункт «Оставить базу готовой к использованию. «.
Жмем ОК, дожидаемся завершения и переходим к добавлению базы на сервер 1С.
Добавляем базу на сервер 1С.
Запускаем в 1С настройку добавление информационной базы и выбираем пункт «Создание новой информационной базы»
На следующем шаге должен быть отмечен пункт «Создание информационной базы без конфигурации..»
Вписываем имя базы и указываем тип расположения информационной базы «На сервере 1С предприятия»
Указываем настройки для подключения к базе сервера MS SQL
Резервное копирование и восстановление информационной базы 1С
Есть множество причин, по которым необходимо выполнять резервное копирование базы данных. Среди них атака вирусов, скачки напряжения или даже атмосферные явления. Кроме того, следует всегда делать резервное копирование, когда вы выполняете обновление программы.
Регулярное создание архивных копий заметно сократит возможность потери важной информации, которая хранится в базе.
Сегодня расскажем, как выполнить резервное копирование и восстановление информационной базы 1С на примере «1С:Бухгалтерия 8 редакция 3.0».
Важно: доступ к настройкам резервного копирования в программах 1С есть только у пользователя с правами «Администратор».
Создаем копию информационной базы 1С
К такому варианту чаще всего обращаются перед обновлением системы и внесением существенных изменений. Если у вас файловая база, то самый быстрый и удобный вариант — копирование файла *.1CD.
Чтобы узнать, где находится база, нужно запустить систему. При запуске посмотрите на строчку с расположением файла базы.
Далее нужно перейти по этому пути и переместить копию файла туда, где он будет хранится.
Во время этой операции в базе нельзя производить действия с объектами конфигурации.
Когда потребуется восстановить базу из файла, замените файл *.1CD в папке базы данных.
Выгрузка информационной базы через конфигуратор
Есть и другой способ сделать резервное копирование. Для этого варианта в программе 1С нужно активизировать конфигуратор и выполнить выгрузку базы в файл с расширением dt.
Шаг № 1. Открываем конфигуратор.
Шаг № 2. «Администрирование» — «Выгрузить информационную базу».
Шаг № 3. Выбрать папку, куда будем выгружать БД в файл *.dt;
Шаг № 4. Ожидаем сообщение системы об успешной выгрузке. Оно появится внизу слева.
Настраиваем автоматическое резервное копирование
Чтобы выполнялось регулярное сохранение базы, лучше применять автоматическое резервное копирование в 1С.
В типовых конфигурациях есть инструменты для настройки этого процесса для информационной базы в файловом варианте.
Зайдите в «НСИ и администрирование». Затем «Поддержка и обслуживание» — «Резервное копирование и восстановление».
У вас будут варианты для сохранения копии. Система предложит:
Через ссылку «Настройка резервного копирования» вы сможете выбрать:
Обратите внимание! Такой механизм не подойдет для клиент-серверной базы.
В этом случае автоматическое резервное копирование данных в 1С 8.3 нужно будет выполнять через СУБД. А для этого нужно понимать структуру и механизмы СУБД.
Если у вас это вызывает сложности, то лучше обратитесь за помощью к нашим специалистам.
Восстановление базы 1С из резервной копии
Администратору важно не только уметь создавать копии базы данных или настраивать автоматическое резервное копирование, но и знать, как в случае необходимости восстановить базу.
Итак, у вас уже есть резервная копия информационной базы 1С 8.3.
Давайте загрузим ее в программу. Только обязательно сделайте перед этим резервную копию.
Режим конфигуратор
Если вы создавали архивную копию базы 1С через Конфигуратор, то в этом же режиме запустите базу 1С 8.3, куда вы собираетесь загрузить файл для восстановления.
Выберите «Администрирование» — «Загрузить информационную базу».
Далее в окне нажимаем на файл сохраненной резервной копии с разрешением *.dt. Затем «Открыть».
Затем программа выдаст предупреждение и спросит, продолжить ли загрузку. Отвечаем «Да».
Внизу окна в строке можно будет следить за статусом загрузки.
Уже в завершении загрузки появится сообщение системы с предложением перезапустить Конфигуратор. Нажимаем «Нет». И запускаем информационную базу.
Режим пользователя
Если вы создавали копию через автоматическое резервное копирование или в пользовательском режиме в разделе раздел «Администрирование» — «Обслуживание» — «Резервное копирование и восстановление», то следует воспользоваться следующим механизмом.
В этом же разделе нужно будет и загружать файл архива.
Когда вы сохраняли копию, то информация архивировалась Zip — WinRaR. Поэтому резервная копия располагается в файле с расширением *.zip.
Теперь восстановим информацию из этой резервной копии. Для этого зайдите в «Администрирование» — «Обслуживание».
Затем в разделе «Резервное копирование и восстановление» следует нажать «Восстановление из резервной копии».
Программа запросит указать путь к файлу резервной копии для выполнения операции по восстановлению.
В архивной папке выберите нужный файл. Это полностью упакованный в архив файл ИБ 1С 8.3 — файл *.CD. В его названии должны быть прописаны дата и время, когда была создана копия. Так будет удобно выбрать верный файл.
Далее выбирайте «Открыть», а затем нажмите «Восстановить данные».
Подождите до завершения операции, а затем приступайте к работе в восстановленной базе 1С.
Восстановление базы 1С Предприятие (DBF) после форматирования
Как выяснилось, резервная копия данной базы у клиента более, чем годовой давности.
Первый этап в решении подобных задач – это создание поблочной копии оригинального накопителя (или как принято писать со времен, когда носителями были только накопители на гибких и жестких магнитных дисках – посекторной). При вычитывании обнаруживается нестабильная скорость чтения, что говорит о серьезном износе NAND памяти (многократное чтение NAND контроллером страниц NAND памяти и коррекция ошибок за счет избыточности кодов коррекции ошибок (ECC ) весьма ресурсоемкая операции, что в итоге влияет на скорость чтения). При наличии непрочитанных участков необходимо заполнить их паттерном, который в дальнейшем нам поможет идентифицировать файлы, которые не были вычитаны целиком.
Далее приступаем к анализу. Необходимо установить, какая файловая система и в каких границах ранее была на USB flash. То есть, необходимо выполнить поиск регулярных выражений, характерных для различных метаданных файловых систем, но прежде, чем его начать, проверим простой вариант, который подразумевает, что границы разделов прежние. Для этого установим текущие параметры файловой системы.
рис. 2
В нашем случае видим по смещению 0x1C2 типа раздела 0x0B, означающее, что на данный момент на USB накопителе есть раздел FAT32, который начинается с 0x80 сектора (DWORD по смещению 0x1C6), длиной 0x003C2000 секторов (DWORD по смещению 0x1CA). Переходим к boot сектору описанного раздела в сектор 0x80 (в файле образа байтах 0x10000)
рис. 3
Необходимо вычислить начальную точку отсчета, то есть место нулевого кластера, относительно которого рассчитывается пространство, а также определить размер кластера.
Выполним проверку на предмет отсутствия записей в таблице размещения файлов и проведем процедуру сравнения копий на предмет разночтений.
Рис. 4
Сравнение копий FAT показало, что разночтения отсутствуют. Анализ содержимого одной из копий FAT показал, что согласно таблицы на разделе заполнен только один кластер.
Далее необходимо оценить корневой каталог на предмет удаленных записей. Позиция первого кластера корневого каталога указывается в boot сектор по смещению 0x2C=0x00000002. Для второго кластера в FAT указано FF FF FF 0F, что означает конец цепочки, то есть корневой каталог состоит из одного кластера.
рис. 5
По адресу, рассчитанному выше, мы видим корневую директорию (корневой каталог), в которой содержится единственная 32-байтная запись. По смещению 0x0B мы видим значение 0x08, которое указывает на тип записи – метка тома. Тот факт, что таблицы размещения файлов заполнены нулями, и в корневом каталоге нет намека на какие-либо иные записи, говорит о том, что данный раздел был отформатирован.
Для проверки предположения о том, что раздел не пересоздавался и все параметры файловой системы корректны, необходимо произвести поиск регулярного выражения 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 со смещением внутри сектора 0x20 (данное выражение признак начала директории FAT32).
рис. 6
При нахождении регулярного выражения необходимо удостовериться, что это действительно директория, по иным признакам, так как в некоторых случаях возможно совпадение и найденное регулярное выражение не является элементом директории. Согласно информации на рис. 6, можно сказать, что данная директория начиналась с 3 кластера (номер текущего кластера директории DWORD содержится в WORD по смещению 0x1A (младшая часть) и WORD по смещению 0x14 (старшая часть)) и описывалась в корневом каталоге, так как по смещениям 0x3A и 0x34 содержатся нули (начальный кластер родительской директории). Проверим, соответствует ли номер кластера данной директории нулевой точке отсчета файловой системы, созданной после форматирования. Для этого номер кластера директории умножим на размер текущего кластера и прибавим к нулевой точке 0x03*0x1000+0x40E000=0x411000. Как видим, расчетный адрес соответствует фактическому нахождению. Установить имя данной директории возможно только в случае, если ранее корневой каталог состоял более, чем из одного кластера, и ссылка на данную директорию была не в первом кластере, так как содержимое первого кластера при форматировании было полностью уничтожено вместе с таблицами размещения файлов.
Далее продолжим поиск регулярного выражения 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 со смещением внутри сектора 0x20.
рис. 7
Повторяем все проверки: 0x04*0x1000+0x40E000=0x412000. Снова видим соответствие положения директории параметрам текущей файловой системы. Но, кроме этого, видим, что есть номер кластера родительской директории 0x03, что говорит о том, что данная директория была вложенной, и взглянув на рис. 6, можно установить имя директории, которая изображена на рис. 7. Итак, согласно рис. 6, по смещению 0x4B видим значение 0x10 — это означает, что данная запись указывает на директорию, а по смещениям 0x5A и 0x54 число 0x00000004 – указатель на 4-й кластер. По смещению 0x40 – имя директории «BIN». Именно таким образом устанавливается взаимосвязь директорий в поврежденном FAT разделе. После выполнения еще некоторого числа проверок директорий в разных участках образа можно сделать окончательный вывод о том, что на данном накопителе состоялось форматирование в границах предшествующей файловой системы и параметры вновь созданной файловой системы унаследованы от предыдущей, то есть дальнейшие аналитические операции нужно проводить в рамках раздела, описанного в таблице разделов с учетом параметров текущей файловой системы.
Зная, что 1С база, состоящая из DBF файлов, должна содержать файл конфигурации 1CV7.MD, выполним поиск последовательности 0x31 0x43 0x56 0x37 0x20 0x20 0x20 0x20 0x4D 0x44. Для того, чтобы уменьшить количество заведомо ложных результатов, поиск лучше выполнять в рамках 32-байтных блоков с нулевым смещением.
Рис. 8
Таким образом, находим все директории, содержащие в себе указатель на файл 1CV7.MD. В нашем случае обнаружилась только одна такая директория, что позволяет предполагать, что мы нашли первый кластер необходимой директории. Далее следует анализ положения родительских директорий, вплоть до корневой директории. Каждая найденная директория прописывается в таблицу FAT (сначала как директория из одного кластера, посредством записи FF FF FF 0F для соответствующего элемента таблицы). Также в корневой директории прописывается ссылка на дочерний объект.
На текущем этапе мы выполним копирование найденных файлов с предположением об их непрерывности, так как обе копии FAT не содержат информации о фрагментации (напомним, что они были безвозвратно уничтожены системным администратором в результате необдуманного форматирования USB flash). После копирования директории 1С базы анализируем количество файлов. Учитывая, что фрагмент директории был размером в один кластер, то извлекли мы не более 126 файлов, что явно намного меньше, чем должно быть в директории с DBF и CDX файлами, относящимися к 1С базе. Примерно такой же результат выдадут программы автоматического восстановления, о чем свидетельствует результат, полученный системным администратором посредством использования R-Studio.
Среди извлеченных файлов есть 1CV7.MD (файл конфигурации) и 1СV7.DD (файл словаря данных). После выполнения проверки целостности создадим у себя на диске временную папку, куда поместим 1CV7.MD. Укажем данный путь при добавлении новой базы и откроем конфигуратор, посредством которого создадим чистую базу на основании этой конфигурации. Сравним сформированный DD файл с восстановленным, если описания и количество справочников идентичны, то никаких дополнительных действий не требуется, и, имея полный список файлов, можно приступать к поиску остальных фрагментов директории 1С базы. Для этого необходимо осуществить поиск последовательностей из ASCII кодов символов, используемых в именах недостающих DBF файлов. По мере обнаружения фрагментов директории дописывать в таблицу размещения файлов продолжение цепочки. После каждой операции дополнения цепочки директории выполнять копирование файлов и анализировать, насколько сократилась количество недостающих DBF файлов, и вновь формировать последовательность ASCII кодов символов для поиска следующего фрагмента.
рис. 9
Также необходимо помнить, что при записи цепочки фрагментов директории в таблицу размещения файлов, необходимо анализировать фрагменты, чтобы стыковались LFN записи. В случае только коротких записей цепочку можно писать с любым порядком фрагментов.
В данном случае выполнив поиск 5 последовательностей удалось найти все остальные фрагменты директории с базой 1С.
После того, как построена полная цепочка фрагментов директории, выполняем повторное копирование уже всех файлов 1С базы с предположением об их непрерывности. Пользовательская информация содержится в DBF файлах, поэтому необходимо проверить их целостность.
Основной метод контроля целостности DBF файла – это проверка информации, содержащейся в служебном заголовке и соответствует ли содержимое файла описанию в заголовке.
рис. 10
Первоначально проводится оценка заголовка: проверяется его длина, указанная по смещению 0x08, приводит ли указанное в нем смещение на конечный маркер 0x0D. Записи полей базы, начиная со смещения 0x20, описываются 32-байтовыми записями, в которых по смещению 0x00 следует имя поля, по смещению 0x0B тип поля, по смещению 0x10 – размер поля. Сумма размеров полей +1 (один дополнительный байт для каждой записи в базе является статусом записи в DBF) должна равняться содержимому по смещению 0x0A (размер одной записи в базе). На рисунке DBF файлы мы видим следующие длины полей: 0x09+0x10+0x10+0x10+0x10+0x10+0x01=0x5A.
Проведем проверку корректности размера файла. Для этого выполняем умножение количества записей, которое указано в заголовке по смещению 0x04 на размер одной записи в базе по смещению 0x0A с последующим сложением с содержимым по смещению 0x08.
0x00000003*0x005A+0xE1=0x01EF. По полученному смещению должен находиться маркер окончания файла 0x1A.
Для контроля целостности содержимого полей можно использовать визуальный метод.
рис. 11
В таком вариант просмотра нужно пролистывать содержимое записей от начала и до конца. В случае если заполнение однородное, в каждом поле располагаются типы данных, характерные для описанного в заголовке и инородного содержимого нет, то по завершении просмотра DBF файла можно сделать вывод о корректности его содержимого.
При обнаружении содержимого, не соответствующего описанию поля в заголовке базы, необходимо установить точное место, с которого начинаются некорректные данные.
Рис. 12
Исходя из описания полей в заголовке и содержимого конкретного DBF файла, можно формировать предположительные ASCII последовательности, которые должны находиться по заданным смещениями в недостающих фрагментах. При отсутствии однотипных баз на одном из накопителей (в том числе и файловых копий одной и той же базы) такой метод позволит относительно быстро найти все недостающие фрагменты в образе накопителя. Отдельно отметим, что возникнут дополнительные сложности в стыковке фрагментов, если размер записи в DBF файле маленький или кратен 16. При наличии иных однотипных баз задача будет многократно усложнена (это утверждение справедливо на всех этапах работ, начиная с поиска фрагментов нужной директории).
Необходимо проверить целостность каждого DBF файла, коих в одной 1С базе несколько сотен. По прохождении всех проверок и сборов фрагментов файлов последует финальная проверка в конфигураторе 1С Предприятия.
рис. 13
В идеальном варианте по результатам тестирования должны пройти успешно все пункты, отмеченные в чекбоксах. Если обнаруживаются ошибки по первым двум пунктам, то необходимо проанализировать лог ошибок в конфигураторе и выяснить, в каких DBF файлах присутствуют инородные данные, которые не были обнаружены при проверках. Если обнаруживаются ошибки при проверке логической целостности, то опять же необходимо анализировать лог ошибок, чтобы выяснить, заключается ли проблема базы в качестве ее сбора, либо в ошибках, допущенных разработчиками конфигурации 1С.
Обратим внимание на тот факт, что если бы данная USB flash не была отформатирована, то после ее вычитки процедура восстановления данных была бы значительно более простой, что сильно бы отразилось на стоимости и сроке выполнения работ в меньшую сторону. В заключение, хотелось бы предостеречь всех пользователей и обслуживающий персонал от необдуманных действий в аварийных ситуациях, которые многократно усугубляют проблему, а также пожелать почаще выполнять операции резервного копирования.