Висит восстановление из копии 1с
Обновлено: 05.07.2024
👍 Смотрите как восстановить повреждённую или удалённую базу 1С (на примере «1С: Предприятие 8.3»). Что делать, если программа не запускается, сама закрывается или вылетает с ошибкой.
Продукты компании 1С являются таким же программным обеспечением, как и любое другое. Информация, которую пользователи вносят в свои базы данных сохраняется в файлах, из которых можно создавать резервные копии или восстанавливать в случае повреждения или удаления. Часто для этого достаточно встроенных в «1С: Предприятие» инструментов, но и о стороннем программном обеспечении также забывать не стоит. Поехали!
1:15 - Файлы базы данных 1С.
2:40 - Признаки и причины повреждения базы 1С.
3:25 - Создание и восстановление из резервной копии базы 1С.
4:22 - Восстановление повреждённой информационной базы 1С.
4:41 - Восстановление с помощью Конфигуратора.
5:13 - Восстановление с помощью chdbfl.exe.
6:36 - Восстановление с помощью НЕХ-редактора.
7:22 - Как восстановить удалённую информационную базу 1С.
Все описанные в данной статье способы восстановления базы данных 1С показаны на примере платформы «1С: Предприятие 8.3». Но эта информация также актуальна для других программ и конфигураций платформы.
• 1С: Зарплата и управление персоналом
• 1С: Управление торговлей
• 1С: Управление Холдингом
• 1С: Управление предприятием
• 1С: Предприятие. Управление производственным предприятием
• 1С: Комплексная автоматизация
• 1С: Управление небольшой фирмой
• 1С: Отчётность предпринимателя
• 1С: Платёжные документы
• 1С: Бухгалтерия государственного учреждения
• 1С: Зарплата и кадры бюджетного учреждения
• 1С: Свод отчётов
• 1С: Бюджетная отчётность
• 1С: Документооборот государственного учреждения
• 1С: Государственные и муниципальные закупки
• 1С: Бюджет поселения
• 1С: Бюджет муниципального образования
• 1С: Электронное обучение и пр.
На этом всё. Ставьте лайк и подписывайтесь на наш канал. Задавайте интересующие по видео вопросы в комментариях. Всем спасибо за просмотр. Всем пока.
(6) 4 часа прошло, база со всеми логами восстановилась минут за 10.
Эта же база, но полный бэкап без логов транзакций восстанавливается и переходит в нормальное состояние.
(8) Пробовал с разных серверов через разные консоли заходить - через английскую и через русскую, ответы однозначные как в subj
use skip
отвечает так:
Database 'skip' cannot be opened. It is in the middle of a restore.
А лог иначе растёт если не бэкапить.
Activiti Monitor пишет что с этой базой сейчас никто не работает (11) Да кстати. я вот тоже думаю, у меня тут упала база. а бекап только ночной, кое что нужное потерялось.
Бекап лога делать не хочтеся, наверное то что очень нужно буду писать в MySQL в процессе дня.
(10) указал момент времени и выбрал всё из предложенного списка - полный бэкап и все логи.
(12) 0 строк, с десяток колонок.
(15) restore database [your] with recoveryоно (gui), похоже, само базу в это состояние не перевело. Юзайте православные скрипты. (16) ну так в том и цель топика.
Меня бы устроил такой порядок - восстановил из gui потом дополнительно запустил бы скрипт, чтобы вывести базу из ступора. (17) ну так запустите. я че-т не понимаю что вас останавливает.. попробуйте посмотреть на скрипт, генерируемый gui - в окне восстановления сверху нажмите script-> to new window (или как-то так). И посмотрите что там в самой последней команде restore - with recovery или with norecovery..
(18) почему gui не работает? Зачем он тогда нужен?
Допустим потрачу время, найду способ восстановления с помощью скриптов.
Через какой-то время забуду или в отпуск уеду, другой человек так же должен мучатся?
в gui в раздере параметры в группе окна Состояние восстановления по умолчанию выбран флаг restore with recovery
Попробую пока скриптом и отпишусь. Но мне не нравится такой способ.
(11) можно в 2-х словах сказать как правильно обеспечить возможность восстановления базы с максимальной потерей времени 2 часа?
(18) спасибо виден конец. ))
Как последнюю строку записать? Так?
RESTORE LOG [МояБаза] FROM DISK = N'F:\BackUp_sql\МояБаза_backup_201009301500.trn' WITH FILE = 1, RECOVERY
RESTORE DATABASE [МояБаза] FROM DISK = N'F:\BackUp_sql\МояБаза_backup_201009300425.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10
GO
RESTORE LOG [МояБаза] FROM DISK = N'F:\BackUp_sql\МояБаза_backup_201009300700.trn' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10
GO
RESTORE LOG [МояБаза] FROM DISK = N'F:\BackUp_sql\МояБаза_backup_201009300900.trn' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10
GO
RESTORE LOG [МояБаза] FROM DISK = N'F:\BackUp_sql\МояБаза_backup_201009301100.trn' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10
GO
RESTORE LOG [МояБаза] FROM DISK = N'F:\BackUp_sql\МояБаза_backup_201009301300.trn' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10
GO
RESTORE LOG [МояБаза] FROM DISK = N'F:\BackUp_sql\МояБаза_backup_201009301500.trn' WITH FILE = 1, NOUNLOAD, STATS = 10, STOPAT = N'2010-09-30T15:24:36'
GO
З.Ы. А сколько база весит-то, что бэкап журнала каждые 2 часа делается?
(21) 8Гб SQL база, 10Гб лог
через день сжатие базы данных
+(20) первая и последние строки, соответственно так:
WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 10
WITH FILE = 1, RECOVERY, NOUNLOAD, STATS = 10
База восстановилась, подключу её обратно к 1С-ке, проверю.
А как gui заставить не на момент времени восстанавливать, а. чтобы как в этом ручном скрипте? Неужели всегда руками подправлять?
(20) все ясно, gui нормально отработал. Смотрите:В последней команде стоит STOPAT = N'2010-09-30T15:24:36'
И там же: FROM DISK = N'F:\BackUp_sql\МояБаза_backup_201009301500.trn', т.е. время создания бэкапа: 201009301500. Т.е. вы пытаетесь восстановиться на несуществующую в ваших бэкапах точку времени. SQL Server понимает, что такого времени нет и оставляет базу данных в состоянии restoring, чтобы вы могли накатить следующие бэкапы, содержащие в себе это время. (24) а если это последний бэкап, как сказать об этом? смотреть время последнего лога и устанавливать это время? Или дату начала или дату окончания(Start date Finish Date)? Перед тем как делать восстановление из бэкапа, сделал полный бэкап, поэтому пришлось в gui вводить время чуть больше чем последний лог транзакций и меньше чем последний полный бэкап. (26) MaxS почитайте в BOL про цепочку восстановления. Вы всегда начинаете восстановление с полного бэкапа, а затем, последовательно, "накатываете" резервные копии журналов транзакций. В 2005-м sql server'e полный бэкап не прерывает цепочку журналов (т.е. после снятия последнего полного бэкапа надо было сделать еще одну резервную копию журнала транзакций и использовать ее в своей, "использованной" цепочке) и не поддерживает восстановление на момент времени. Из полного бэкапа вы можете восстановиться только на момент создания бэкапа.
Т.е., чтобы вам восстановиться на указанный вами момент времени надо снять еще одну копию журнала транзакций (после полной резервной копии) и проделать все тоже самое, что вы уже делали, но в качестве последней копии указать последнюю копию журнала транзакций. Фух.. надеюсь, понятно :) сколько делается полный бэкап? может есть смысл делать полные копии вместо бэкапа лога?
---
хотя к текущей ситуации это отношения не имеет ну и нафига оно надоть?
симпл работает шустрее, чем фулл
(27) понятно, нужно будет потренироваться пока база не перешла на полную нагрузку ;) Можно было поступить так. сделать бэкап лога транзакций, потом полный бэкап, а потом восстановить на нужное время до момента возникновения проблем.
Но попробовал глянуть на скрипт для другой базы. Логов там до конца дня, я задал момент времени 13 часов, вот последняя строка:
_backup_201009301400.trn' WITH FILE = 1, NOUNLOAD, STATS = 10, STOPAT = N'2010-09-30T13:16:19'
RECOVERY там нет
(28) не проверял время, проверил объем. полный бэкап порядка 4Гб, все логи за весь день порядка 600Мб в сумме. А диск для бэкапов не резиновый ))
(32) слив защитан(33) RECOVERY можно не указывать, оно по-умолчанию. Восстановилось нормально? (33) 20 гб база бэкапится в онлайн режиме 51 сек
потом 40 минут сжимается до 1,5 гб
но я не навязываю свою точку зрения
(34) не пробовал ещё ))
(29) спасибо за ссылку. давно подобное читал, но потерял ссылки. во времена 2000 серверов даже держал в голове ;)
(35) самым важным будет время восстановления после сбоя. В течение дня все сервера загружены делом, сжимать и разжимать нужно время и ресурсы.
и теперь база данных застряла в состоянии восстановления.
некоторые люди предположили, что это потому, что в резервной копии не было файла журнала, и его нужно было свернуть с помощью:
кроме того, что, конечно, не удается:
и именно то, что вы хотите в катастрофической ситуации, - это восстановление, которое не будет работа.
резервная копия содержит как данные, так и файл журнала:
вам нужно использовать WITH RECOVERY опция, с вашей базой данных RESTORE команда, чтобы привести вашу базу данных в режиме онлайн в рамках процесса восстановления.
Это, конечно, только если вы не собираетесь восстанавливать резервные копии журналов транзакций, т. е. вы хотите восстановить резервную копию базы данных, а затем иметь доступ к базе данных.
ваша команда должна выглядеть так,
У меня была эта ситуация восстановление базы данных в экземпляр SQL Server 2005 Standard Edition с помощью Symantec Backup Exec 11d. После завершения задания восстановления база данных осталась в состоянии" восстановление". У меня не было проблем с дисковым пространством-база данных просто не вышла из состояния "восстановление".
Я запустил следующий запрос к экземпляру SQL Server и обнаружил, что база данных сразу стала полезной:
вот как вы это делаете:
- остановить службу (MSSQLSERVER);
- переименовать или удалить файлы базы данных и журналов (C:\Program файлы\Microsoft SQL Server\MSSQL.1\MSSQL\данные. ) или где у вас есть файлы;
- запустить службу (MSSQLSERVER);
- удалить базу данных с проблемы;
- восстановить базу данных.
У меня был аналогичный инцидент с остановкой сервера-получателя доставки журналов. После команды удалить сервер из доставки журналов и остановить доставку журналов с первичного сервера база данных на вторичном сервере застряла в восстановлении состояния после команды
восстановление базы данных успешно обработано 0 страниц за 18.530 секунд (0.000 MB / sec).
база данных была использована снова после тех 18 секунд.
который исправил проблему. Сначала у меня возникли проблемы из-за имени базы данных, содержащей специальные символы. Я решил это, добавив двойные кавычки вокруг-одиночные кавычки не будут работать, давая " неправильный синтаксис рядом . " ошибка.
Это было минимальное решение, которое я пытался решить эту проблему (застрявшая база данных в состоянии восстановления), и я надеюсь, что его можно применить к более случаи.
OK, у меня есть аналогичная проблема, и точно так же, как это было в случае Pauk, это было вызвано тем, что сервер исчерпал дисковое пространство при восстановлении и поэтому вызвал постоянное состояние восстановления. Как завершить это состояние без остановки служб SQL Server?
Я нашел решение :)
с опцией восстановления используется по умолчанию при выполнении команд RESTORE DATABASE/RESTORE LOG. Если вы застряли в процессе "восстановления", вы можете вернуть базу данных в онлайн-состояние, выполнив:
Если есть необходимость в восстановлении нескольких файлов, команды CLI требуют с NORECOVERY и с восстановлением соответственно-только последний файл в команде должен иметь с восстановлением, чтобы вернуть базу данных онлайн:
можно использовать SQL Server Мастер Management Studio также:
существует также виртуальный процесс восстановления, но вам придется использовать сторонние решения. Как правило, вы можете использовать резервную копию базы данных в онлайн базе. ApexSQL и Idera имеют свои собственные решения. Обзор по SQL Hammer о восстановлении ApexSQL. Виртуальный восстанавливая хорошее решение, если вы имеете дело с большим количеством резервных копий. Процесс восстановления намного быстрее, а также может сэкономить много места на диске. Вы можете взгляните на инфографики здесь для некоторого сравнения.
Это может быть довольно очевидно, но это меня только что споткнулось:
Если вы берете резервную копию хвостового журнала, эта проблема также может быть вызвана тем, что эта опция включена в Мастере восстановления SSMS - " оставить исходную базу данных в состоянии восстановления (с NORECOVERY)"
если клиент, который выдал RESTORE DATABASE команда отключается во время восстановления, Восстановление будет застрять.
странно, что сервер, когда ему говорят восстановить базу данных с помощью клиентского соединения, не завершит восстановление, если клиент не будет подключен все время.
У меня была ситуация, когда моя база данных показывала состояние восстановления, и я не мог запускать какие-либо запросы и не мог подключиться к нашему программному обеспечению.
Что я сделала, чтобы выйти из этой ситуации:
остановить все связанные службы SQL из windows сервисы.
Я открыл папку данных, где файлы Ldf и Mdf находятся в каталоге SQL, обычно это похоже : "C:\Program файлы***********\MSSQL\DATA
затем я скопировал файлы Ldf и Mdf базы данных: [имя БД].mdf и [имя БД]_log.ldf
Я скопировал оба файла в другую папку.
затем я запустил все службы, связанные с SQL (на шаге 1) снова из служб windows.
запустил мою MS SQL Management studio с обычным логином.
Правой Кнопкой Мыши на базе данных виновника и нажмите Удалить (чтобы удалить базу данных на всех).
все файлы LDF и MDF, связанные с этой базой данных, ушли из папки данных (упомянутой в шаге 2).
создал новую базу данных с тем же именем (то же имя, которое я удалил в шаге 6 - база данных виновника).
затем [имя базы данных] - > щелкните правой кнопкой мыши - > задачи - > отключить.
затем я скопировал оба файла (с шага 3) обратно в папку данных (Шаг 2).
[имя базы данных] - >щелкните правой кнопкой мыши - > задачи - > вывести в интернет.
У меня было . в моем имени базы данных, и запрос не работал из-за этого (говоря неправильный синтаксис рядом '.Затем я понял, что мне нужна скобка для имени:
У меня была эта проблема, когда я также получил ошибку TCP в журнале событий.
падение БД с sql или щелкните правой кнопкой мыши на нем в диспетчере " удалить" И восстановить снова.
Я фактически начал делать это по умолчанию. Сценарий падение БД, воссоздать, а затем восстановить.
по умолчанию every RESTORE DATABASE входит RECOVERY настройка. Параметры "NORECOVERY" в основном сообщают SQL Server, что база данных ожидает больше файлов восстановления (может быть DIFF файл и LOG файл и, может включать файл резервной копии хвостового журнала, если это возможно). Параметры "восстановление", завершить все транзакции и пусть база данных готова к выполнению транзакций.
- если ваша база данных настроена простой модель восстановления, вы можете выполнять только полное восстановить с помощью NORECOVERY вариант, когда у вас есть DIFF резервное копирование. Нет!--12-->LOG резервное копирование разрешается в простой модель восстановления базы данных.
- в противном случае, если база данных настроена с полное или МАССОВАЯ РЕГИСТРАЦИЯ модель восстановления, вы можете выполнять полное восстановление с последующим NORECOVERY опция, затем выполните DIFF следовал по NORECOVERY и, наконец, выполнить LOG восстановить с помощью .
помните, что ПОСЛЕДНИЙ ЗАПРОС ВОССТАНОВЛЕНИЯ ДОЛЖЕН ИМЕТЬ RECOVERY опции. Это может быть явный способ или нет. В термах T-SQL ситуация:
- USE [master] GO RESTORE DATABASE Database_name FROM DISK = N'\path_of_backup_file.bak WITH FILE = 1, [REPLACE],NOUNLOAD, RECOVERY -- This option could be omitted. GO
С заменой опция должна использоваться с осторожностью, так как это может привести к потере данных
или, если вы выполняете Полное и DIFF резервное копирование, вы можете использовать это
- USE [master] GO -- Perform a Tail-Log backup, if possible. BACKUP LOG Database_name GO -- Restoring a FULL backup RESTORE DATABASE Database_name FROM DISK = N'\path_of_backup_file.bak' WITH FILE = 1, NOUNLOAD,NORECOVERY GO -- Restore the last DIFF backup RESTORE DATABASE Database_name FROM DISK = N'\path_of_DIFF_backup_file.bak' WITH FILE = 1, NORECOVERY,NOUNLOAD GO -- Restore a Log backup RESTORE LOG Database_name FROM DISK = N'path_of_LOG_backup_file.trn' WITH FILE = 2, RECOVERY, NOUNLOAD GO
конечно, вы можете выполнить восстановление с параметром статистика = 10 это говорит SQL Server сообщать о каждом 10% завершено.
если вы предпочитаете, вы можете наблюдать процесс или восстановление в режиме реального времени на основе запроса. Как следует:
надеюсь, что это поможет.
также может возникнуть проблема с удалением застрявшей базы данных, если включен снимок. Для меня это сработало:
в моем случае этого было достаточно, чтобы удалить базу данных, который висел в состоянии "восстановление. " С помощью команды SQL
затем я щелкнул правой кнопкой мыши на базы данных и выбранными обновить который удалил запись в Management Studio. После этого я сделал новое восстановление, которое работало нормально (обратите внимание, что вывод его в автономном режиме не работал, перезапуск службы SQL не работал, перезагрузка сервера также не работала).
вы пробовали запустить только проверку? Просто чтобы убедиться, что это резервная копия.
В статье показаны способы восстановления базы 1С с помощью встроенных в программу инструментов или сторонних приложений . Как создать и восстановить резервную копию базы данных. Для большинства пользователей продуктов компании 1С , повреждение или утеря базы «1С: Предприятие» есть тем, о чём даже боятся говорить. Для них, задача по восстановлению базы данных кажется просто нереальной, а её утеря страшной трагедией.
На самом деле, продукты компании 1С являются таким же программным обеспечением, как и любое другое. Информация, которую пользователи вносят в свои базы данных сохраняется в файлах, из которых можно создавать резервные копии или восстанавливать в случае повреждения или удаления. Часто для этого достаточно встроенных в «1С: Предприятие» инструментов, но и о стороннем программном обеспечении также забывать не стоит.
Файлы базы данных 1С
Для лучшего понимания того, каким образом происходит восстановление повреждённых или утерянных баз 1С, давайте ознакомимся с файлами, в которых они сохраняются.
По умолчанию, каталогом информационной базы, в котором кроме файла самой базы 1С сохраняются все файлы, которые имеют к ней отношение, является папка в Документах пользователя:
C:\Users\Имя Пользователя\Documents\InfoBase
В этой папке хранятся все файлы, которые имеют отношение к данной базе данных.
К таким файлам относятся:
- *.1CD – файл самой базы данных, который по умолчанию имеет название 1Cv8.1CD. Данный файл включает в себя все данные, которые внесены в базу данных, а также их конфигурацию;
- *.cf, *.cfu (*.cfl), *.dt, *.epf (*.erf) – конфигурационные файлы базы данных;
- *.log, *.lgf, *.lgp, *.elf – лог файлы;
- *.cdn – файл блокировки базы данных 1С;
- *.efd – архивный файл 1С;
- *.mft – вспомогательный файл конфигурации шаблона;
- *.st – файл шаблонов текстов
- *.mxl – файл печатных форм базы данных 1С;
- *.grs – файл графических схем базы данных 1С;
- *.geo – файл географических схем базы данных 1С.
Признаки и причины повреждения базы 1С
Причины повреждения базы 1С могут быть физического или логического происхождения.
Последствия физических причин повреждения баз банных самые тяжелые, так как связаны с повреждением носителя информации, на котором хранятся данные. Это может быть повреждение внешнего или встроенного жесткого диска, оптического носителя информации, флешки или карты памяти. В данном случае, чтобы иметь возможность восстановить базу 1С, необходимо вернуть работоспособность носителю информации.
Логические повреждения баз происходят в результате сбоев в работе программного обеспечения, неправильного или внезапного отключения компьютера или носителя информации, неправильная работа сетевого оборудования, а также вирусы и деятельность вредоносных программ.
Перечислю действия, которые возможны при попытке избавиться от подобной ситуации:
-
. .
- Создать чистую информационную базу данных и загрузить в нее сделанную резервную копию. .
- Использовать утилиту chdbfl.exe, которая поставляется в составе программного комплекса.
Теперь рассмотрим каждый пункт подробней.
Важно! Обязательно обновите платформу 1С: Предприятие 8.3 до последней версии!
Восстановление резервной копии
Если у Вас настроено ежедневное резервное копирование, то Вам повезло. Нужно просто восстановить последнюю рабочую копию и работать дальше.
Во избежание ошибки советую сначала создать новую, пустую базу данных и загрузку делать в нее.
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
Получите понятные самоучители по 1С бесплатно:
Но, к сожалению, на многих предприятиях пренебрегают регулярным резервированием базы. Поэтому придется пытаться восстановить поврежденный экземпляр.
Делаем резервную копию поврежденной информационной базы
Перед любыми дальнейшими действиями необходимо сделать резервную копию базы.
Если повреждения в базе данных довольно серьезные, штатная выгрузка может не пройти. В таком случае нужно выйти из конфигуратора, создать новый каталог на диске и скопировать в него файл 1Cv8.1CD. Это и есть база данных:
Кстати, после этого можно попробовать подключиться к этому новому каталогу и запустить программу. Дело в том, что ошибка может таиться в файлах кэша, а в новом каталоге их не будет, и база может нормально запуститься.
Если проблема не исчезла, продолжаем ремонт системы.
Тестирование и исправление базы данных
Насчет настроек данного режима единого мнения нет. Я предпочитаю устанавливать указанные на рисунке.
Но опять же, во время тестирования может возникать критическая ошибка, и действие не завершается.
Тогда пробуем еще один способ.
Использование утилиты chdbfl.exe
Нас интересует только выделенная часть. Далее находим папку с последней установкой платформы, далее каталог bin. Вот в нем и находится искомый файл:
Запускаем его. Запустится программа восстановления информационной базы:
Каждый из описанных способов может/должен привести к исправлению ошибки в файле базы данных.
Смотрите также наше видео про восстановление базы после появления ошибок:
Читайте также: