Как восстановить файл databases

Обновлено: 06.07.2024

Читайте, как восстановить утерянную или удалённую базу MySQL . Как восстановить повреждённые таблицы базы MySQL с помощью myisamchk. База данных MySQL по умолчанию устанавливается на компьютере в папку не диске С:

C:\Program Files\MySQL\MySQL Server 5.7

Но, данные таблиц хранятся в файлах в другой папке на диске С компьютера, это:

C:\ProgramData\MySQL\MySQL Server 5.7\Data

Расположение данных файлов указано в меню Server Status приложения MySQL Workbench, в разделе Server Directories.

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

Файлы базы данных MySQL

Данные каждой базы данных хранятся в папке с её названием, и в зависимости от типа таблицы хранятся в файлах с такими расширениями:

db.opt – файл в котором хранятся характеристики базы данных, указанные при её создании;
.frm – файл структуры таблиц;
.myd – файл, в котором хранятся данные MyISAM таблиц;
.myi – файл, в котором хранятся индексы MyISAM таблиц;
.ibd – файл, в котором хранятся данные и индексы InnoDB таблиц.

Как восстановить базу данных MySQL

Восстановление базы данных MySQL это технически не сложный процесс, но он зависит от множества условий. Для пользователей MySQL Workbench предусмотрена функция Экспорта и Импорта/Восстановления данных баз данных.

Кроме этого, возможно создание резервной копии и восстановление базы данных MySQL с помощью mysqldump (которую мы детально описали в одной из наших статей).

Но эти функции больше относятся к созданию резервных копий данных MySQL с помощью встроенных инструментов. Более продвинутым пользователям или тем, которые не воспользовались вовремя функцией резервирования данных базы MySQL, будет также интересен способ создания копий и восстановления данных баз вручную, методом подстановки описанных выше файлов структуры и данных таблиц:

Создание копии данных таблиц базы MySQL возможно путём копирования файлов структуры и данных (*.opt, *.frm, *.myd, *.myi для MyIsam; *.opt, *.frm, *.ibd для InnoDB) и сохранения их в другой папке.
Восстановление данных таблиц базы MySQL возможно путём подстановки скопированных раннее файлов структуры и данных в папки уже существующих баз (в нашем случае это две базы: my_db и my_db2).

Восстановление утерянной или удалённой базы MySQL

Так, если по какой-то причине вы удалили базу данных MySQL, переустановили Windows или отформатировали жесткий диск, то восстановить её можно описанным выше способом, путём подставки скопированных раннее файлов базы данных в папку с названием базы:

C:\ProgramData\MySQL\MySQL Server 5.7\Data

Если же пользователем заблаговременно не была создана копия файлов базы данных, то их можно восстановить с помощью Hetman Partition Recovery , после чего перенести в нужную папку описанным выше способом.

Запустите Hetman Partition Recovery и просканируйте с его помощью диск на котором хранилась база данных MySQL

Найдите и перейдите с помощью программы в папку C:\ProgramData\MySQL\MySQL Server 5.7\Data ,

или осуществите поиск необходимых файлов базы данных с помощью функции поиска:

Обратите внимание: файлы с данными и форматами таблиц будут иметь название таблицы, а не базы данных.

Перенесите их в папку с названием базы данных.

Запустив после этого MySQL Workbench, помещённые в папку базы восстановленные файлы таблиц будут доступны.

Таким же способом можно восстанавливать утерянные файла дампа (*.sql) или его архив (*.zip, *.gzip, *.bzip2).

Восстановление повреждённых таблиц базы MySQL с помощью myisamchk

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

В результате повреждения из таблицы могут исчезнуть или неправильно отображаться данные, но чаще всего в результате повреждения таблицы пользователи сталкиваются с ошибкой: «Incorrect key file for table: ‘название_таблицы’. Try to repair it»

Для восстановления повреждённых MyISAM таблиц можно использовать команду myisamchk .

Myisamchk работает путём отладки и создания копии .myd файла, с дальнейшей заменой им повреждённого файла. Поэтому, прежде чем использовать данную команду, лучше предварительно создать резервную копию файла таблицы, которую необходимо восстановить.

Так, чтобы восстановить повреждённую таблицу, используйте команду:

myisamchk -r -q ИМЯ_ТАБЛИЦЫ

где, -r -q – это режим быстрого восстановления. В данном случае будет исправлен индексный файл без изменения файла данных. Если в файле данных содержится все необходимое, а удаленные связи указывают на правильные позиции в файле данных, то в результате данной команды таблица будет исправлена.

Если предыдущая команда не даст необходимого результата, то сделайте резервную копию файла данных и выполните команду:

myisamchk -r ИМЯ_ТАБЛИЦЫ

где, -r – это просто режим восстановления. В таком случае из файла данных будут удалены некорректные и утерянные записи, и индексный файл будет создан заново (как описано выше).

Обратите внимание . Если отладку и восстановление таблицы планируется выполнять из командной строки, то предварительно необходимо остановить сервер. Следует отметить, что при выполнении mysqladmin shutdown с удаленного сервера mysqld все еще будет некоторое время работать после завершения mysqladmin, пока не будут остановлены все запросы и сброшены на диск все ключи.

Этот раздел содержит сведения о восстановлении полной резервной копии базы данных с использованием среды SQL Server Management Studio.

Важно!

Перед восстановлением базы данных по модели полного восстановления или восстановления с неполным протоколированием, возможно, необходимо будет выполнить резервное копирование активного журнала транзакций (который называется заключительным фрагментом журнала). Дополнительные сведения см. в статье Создание резервной копии журнала транзакций (SQL Server)).

При восстановлении базы данных из другого экземпляра примите во внимание сведения из раздела Управление метаданными при обеспечении доступности базы данных на другом экземпляре сервера (SQL Server).

Чтобы восстановить зашифрованную базу данных, потребуется доступ к сертификату или асимметричному ключу, использовавшемуся для шифрования этой базы данных. Без сертификата или асимметричного ключа вы не сможете восстановить базу данных. Сохраняйте сертификат, который использовали для шифрования ключа шифрования базы данных, в течение всего периода хранения резервной копии. Дополнительные сведения см. в статье SQL Server Certificates and Asymmetric Keys.

Если восстановить базу данных более старой версии до SQL Server 2019 (15.x), эта база данных будет автоматически обновлена до SQL Server 2019 (15.x). Это исключает возможность использования базы данных с более старой версией Компонент Database Engine. Но это относится к обновлению метаданных и не влияет на уровень совместимости базы данных. Если уровень совместимости пользовательской базы данных до обновления был 100 или выше, после обновления он останется таким же. Если уровень совместимости до обновления был 90, в обновленной базе данных он устанавливается в 100, что является минимально поддерживаемым уровнем совместимости в SQL Server 2019 (15.x). Дополнительные сведения см. в разделе Уровень совместимости инструкции ALTER DATABASE (Transact-SQL).

Как правило, база данных сразу становится доступной. Однако если база данных SQL Server 2005 (9.x) содержит полнотекстовые индексы, то в процессе обновления будет произведен их импорт, сброс или перестроение в зависимости от установленного значения свойства сервера Режим обновления полнотекстового каталога . Если выбран режим обновления Импортировать или Перестроить, то полнотекстовые индексы во время обновления будут недоступны. В зависимости от объема индексируемых данных процесс импорта может занять несколько часов, а повторная сборка — до десяти раз дольше.

Если выбран режим обновления Импорт, а полнотекстовый каталог недоступен, то связанные с ним полнотекстовые индексы будут перестроены. Сведения о просмотре и изменении параметра Режим обновления полнотекстового поиска см. в статье Наблюдение за полнотекстовым поиском для экземпляра сервера и управление им.

Сведения о восстановлении SQL Server из службы хранилища BLOB-объектов Microsoft Azure см. в разделе Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure.

Примеры

A. Восстановление полной резервной копии базы данных

В обозревателе объектов подключитесь к экземпляру компонента Компонент SQL Server Database Engine и разверните его.

Щелкните правой кнопкой мыши узел Базы данных и выберите команду Восстановить базу данных.

Чтобы указать источник и расположение восстанавливаемых резервных наборов данных, используйте страницу Общие , раздел Источник . Выберите один из следующих вариантов.

База данных

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

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

Устройство

Диалоговое окно Выбор устройств резервного копирования .

Носитель данных резервной копии
Выберите тип носителя в раскрывающемся списке Тип носителя данных резервной копии . Примечание. Параметр Лента появляется только в случае, если на компьютере установлен ленточный накопитель, а параметр Устройство резервного копирования — только в случае, если имеется хотя бы одно устройство резервного копирования.

Добавление
В зависимости от типа носителя данных, выбранного в поле Носитель резервной копии , при нажатии кнопки Добавить открывается одно из следующих диалоговых окон. (Если список в поле со списком Тип носителя резервной копии заполнен, кнопка Добавить недоступна.)

Тип носителя данных	.	Описание
Файл	Локальный файл резервной копии	В данном диалоговом окне можно выбрать локальный файл из дерева или указать удаленный файл, используя его полное имя в формате UNC. Дополнительные сведения см. в разделе Устройства резервного копирования (SQL Server).
Устройство	Выбор устройства резервного копирования	В данном диалоговом окне из списка можно выбрать логические устройства резервного копирования, определенные на экземпляре сервера.
Лента	Выбор ленты с резервной копией	В данном диалоговом окне из списка можно выбрать ленточные накопители, физически подключенные к компьютеру, на котором запущен экземпляр SQL Server.
URL-адрес	Выберите расположение файла резервной копии	В этом диалоговом окне можно выбрать существующие учетные данные SQL Server или контейнер хранилища Azure, добавить новый контейнер хранилища Azure с подписанным URL-адресом или сформировать подписанный URL-адрес и учетные данные SQL Server для уже существующего контейнера хранилища. См. также статью Соединение с подпиской Microsoft Azure

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

Содержание
Отображает содержимое носителя выбранного файла, ленты или устройства резервного копирования. Эта кнопка может не работать, если тип носителя — URL-адрес.

Тип носителя резервной копии
Перечисляет выбранные носители.

После добавления нужных устройств в списке Носитель резервной копии нажмите кнопку ОК для возвращения на страницу Общие .

В списке Источник > Устройство > База данных выберите имя базы данных, которую нужно восстановить.

Данный список доступен, только если выбран параметр Устройство . Будут выбраны только те базы данных, резервные копии которых доступны на выбранном устройстве.

В разделе Назначение , в поле База данных автоматически появится имя базы данных для восстановления. Для изменения имени базы данных введите новое имя в окно База данных .

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

В сетке Резервные наборы данных для восстановления выберите нужные резервные наборы. В этой сетке отображаются резервные копии, доступные в указанном месте. По умолчанию предлагается план восстановления. Чтобы переопределить предложенный план восстановления, можно изменить выбранные элементы в сетке. Выбор всех резервных копий, которые зависят от восстановления более ранних копий, отменяется автоматически, как только отменяется выбор более ранних копий. Дополнительные сведения о столбцах сетки Резервные наборы данных для восстановления см. в статье Восстановление базы данных (страница "Общие").

При необходимости нажмите кнопку Файлы на панели Выбор страницы и перейдите в диалоговое окно Файлы . Отсюда можно восстановить базу данных в новое расположение, определив новое место восстановления для каждого файла в сетке Восстановить файлы базы данных как . Дополнительные сведения об этой сетке см. в разделе Восстановление базы данных (страница "Файлы").

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

Параметры WITH (необязательно):

Перезаписать существующую базу данных (WITH REPLACE)

Сохранить параметры репликации (WITH KEEP_REPLICATION)

Ограничить доступ к восстановленной базе данных (WITH RESTRICTED_USER)

Выберите параметр в поле Состояние восстановления . В данном окне определяется состояние базы данных после операции восстановления.

По умолчанию используется схема RESTORE WITH RECOVERY, которая выполняет откат незафиксированных транзакций и после завершения оставляет базу данных работоспособной. Дополнительные журналы транзакций восстановить невозможно. Выберите этот вариант, если выполняется восстановление сразу всех необходимых резервных копий.

Схема RESTORE WITH NORECOVERY оставляет базу данных в нерабочем состоянии и не выполняет откат незафиксированных транзакций. Можно восстановить дополнительные журналы транзакций. Вы не сможете использовать эту базу данных, пока она не будет восстановлена.

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

Создайте резервную копию заключительного фрагмента журнала до восстановления Не для всех сценариев восстановления требуется резервная копия заключительного фрагмента журнала. Дополнительные сведения см. в разделе Сценарии, в которых требуется резервная копия заключительного фрагмента журнала статьи Резервные копии заключительного фрагмента журнала (SQL Server).

Если имеются активные соединения с базой данных, то операция восстановления может завершиться ошибкой. Проверьте окно Закрыть существующие соединения и убедитесь, что все активные соединения между Среда Management Studio и базой данных закрыты. Эта настройка переводит базу данных в однопользовательский режим перед началом процедуры восстановления, а затем возвращает в многопользовательский режим после ее завершения.

Установите флажок Выдавать запрос перед восстановлением каждой резервной копии , если хотите отследить каждую операцию восстановления. Это не требуется, если не нужно наблюдать за состоянием операции восстановления для базы данных большого объема.

Дополнительные сведения об этих параметрах восстановления см. в разделе Восстановление базы данных (страница "Параметры").

Б. Восстановление более ранней резервной копии диска поверх существующей базы данных

В следующем примере восстанавливается более ранняя резервная копия диска из базы данных Sales и перезаписывается существующая база данных Sales .

В обозревателе объектов подключитесь к экземпляру компонента Компонент SQL Server Database Engine и разверните его.

Щелкните правой кнопкой мыши узел Базы данных и выберите команду Восстановить базу данных.

На странице Общие выберите пункт Устройство в разделе Источник .

в разделе Параметры восстановления установите флажок Перезаписать существующую базу данных (WITH REPLACE) .

В разделе Резервная копия заключительного фрагмента журнала снимите флажок Делать резервную копию заключительного фрагмента журнала перед восстановлением.

Не для всех сценариев восстановления требуется резервная копия заключительного фрагмента журнала. Резервная копия заключительного фрагмента журнала не нужна, если точка восстановления содержится в более ранней резервной копии журнала. Кроме того, резервная копия заключительного фрагмента журнала не требуется при перемещении или замещении (перезаписи) базы данных, при котором не нужно восстанавливать ее на определенный момент времени после создания ее последней резервной копии. Дополнительные сведения см. в разделе Резервные копии заключительного фрагмента журнала (SQL Server).

Этот параметр недоступен для баз данных при использовании ПРОСТОЙ модели восстановления.

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

В. Восстановление более ранней резервной копии диска с новым именем базы данных при условии, что исходная база данных по-прежнему существует

В следующем примере восстанавливается более ранняя резервная копия диска из базы данных Sales и создается новая база данных с именем SalesTest . При этом исходная база данных, Sales , все еще существует на сервере.

В обозревателе объектов подключитесь к экземпляру компонента Компонент SQL Server Database Engine и разверните его.

Щелкните правой кнопкой мыши узел Базы данных и выберите команду Восстановить базу данных.

На странице Общие выберите пункт Устройство в разделе Источник .

Если оставить этот флажок установленным, существующая база данных Sales сменит состояние на состояние восстановления.

Г. Восстановление до точки во времени

В следующем примере база данных восстанавливается в состояние на 1:23:17 PM``May 30, 2016 и демонстрируется операция восстановления, использующая несколько резервных копий журналов. Указанная база данных не существует на сервере.

Д. Восстановление резервной копии с помощью службы хранилища Microsoft Azure

Общие шаги

В двух примерах ниже выполняется восстановление базы данных Sales из резервной копии, расположенной в службе хранилища Microsoft Azure. Имя учетной записи хранилища — mystorageaccount . Контейнер называется myfirstcontainer . Для краткости первые шесть шагов перечислены здесь однократно, а все примеры начинаются с шага 7.

Читайте, с помощью каких инструментов можно создать бэкап или восстановить утерянную базу Oracle Database . Рассмотрим как встроенные в базу инструменты так и сторонние приложения. Oracle Database хранит все файлы созданной базы в файлах данных. Часто, для восстановления данных определённой базы , достаточно восстановить её файлы данных и импортировать их в Oracle Database.

Структура базы данных Oracle Database

В процессе работы экземпляр базы данных Oracle Database использует несколько групп файлов, которые следует архивировать для последующего восстановления. Это:

Файлы данных и табличных пространств (*.DBF) .

Название файлов данных и табличных пространств, а также пути к ним можно посмотреть с помощью SQL Plus если выполнить следующий запрос:

В результате работы этого запроса получится подобный отчет:

Конфигурационные файлы базы данных Oracle имеют расширение *.ora и расположены в папке:

C:\oraclexe\app\oracle\product\11.2.0\server\dbs

Самый простой способ определить путь и названия управляющих файлов, это найти в конфигурационном файле *.ORA строку control_files , в которой будут перечислены используемые этим экземпляром управляющие файлы.

Также, чтобы определить названия и пути к управляющим файлам в SQL Plus необходимо выполнить запрос:

SELECT value FROM v$parameter WHERE name = ‘control_files’;

Чтобы узнать имена онлайновых журналов транзакций и пути к ним, необходимо в SQL Plus выполнить следующий запрос:

SELECT member FROM v$logfile;

В результате работы этого запроса получится подобный отчет:

Чтобы определить пути к папкам, где хранятся архивные журналы транзакций, необходимо выполнить такой запрос:

SELECT destination FROM v$archive_dest where status=’VALID’;

В результате работы этого запроса получится отчет:

Как правило, это файлы с расширением *.ora, имя которых начинается с символов PWD.
Например: PWDXE.ora

Путь: C:\oraclexe\app\oracle\product\11.2.0\server\database

Итак, для сохранения, архивирования или бэкапа базы данных Oracle Database, копии именно указанных групп файлов следует создавать, а это:

*.DBF – файлы данных, табличных пространств и управляющие файлы базы данных. Расположены:
C:\oraclexe\app\oracle\oradata\XE
*.ora – файлы конфигурации базы данных и файлы паролей.
Файлы конфигурации:
C:\oraclexe\app\oracle\product\11.2.0\server\dbs
Файлы паролей (PW…ora):
C:\oraclexe\app\oracle\product\11.2.0\server\database
*.LOG – файлы журналов транзакций:
C:\oraclexe\app\oracle\fast_recovery_area\XE\ONLINELOG

где, ХЕ – это название базы данных в нашем случае.

Резервная копия базы данных Oracle Database

Резервную копию базы данных Oracle Database можно создать двумя способами:

Архивации средствами операционной системы.
Используя встроенные инструменты Oracle Application Express – Import / Export.

Архивация средствами операционной системы

Архивация средствами операционной системы подразумевает «ручное» копирование всех рабочих файлов базы данных, таких как:

Файлы табличных пространств.
Управляющие файлы.
Файлы журналов транзакций.
Файлы конфигурации.

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

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

Архивация и восстановление при помощи инструментов Export / Import

Архивацию и восстановление базы данных Oracle Database можно производить с помощью стандартных механизмов Экспорта и Импорта в Oracle. Для повышения надежности сохранности данных необходимо периодически, в зависимости от интенсивности работы с базой, производить полный экспорт. При достаточно интенсивном внесении изменений в данные, необходимо делать экспорт один раз в неделю.

Читайте, как восстановить удалённую базу MSSQL используя встроенные в приложение инструменты или сторонние программы . Рассмотрим причины, по которым база может быть утеряна, а также способы восстановления для каждого из них. SQL Server – это система управления реляционными базами данных (СУБД) от Microsoft, которая изначально разрабатывалась компанией как конкурент набиравшим популярность Oracle Database и MySQL .

Основным инструментом интерфейса SQL Server является Microsoft SQL Server Management Studio (SSMS).

Как и большинство СУБД Microsoft SQL Server поддерживает стандарт ANSI SQL. Но, СУБД от Microsoft также использует собственную реализацию стандарта – T-SQL.

Файлы системы Microsoft SQL Server

Файлы базы SQL Server по умолчанию сохраняются на диске С компьютера:

C:\Program Files\Microsoft SQL Server

Причём под каждую базу создаётся отдельная папка с её названием. Например, в нашем случае создано две базы данных Microsoft SQL Server: MSSQL13.SQLEXPRESS, MSSQL13.MSSQLHETMAN.

Данные любой из баз данных MSSQL хранятся в рабочих системных файлах, которых есть три типа:

*.mdf – это первичный файл данных базы. В таком файле содержатся сведения, которые необходимы для запуска базы, ссылки на другие файлы базы, данные и объекты пользователя. В .mdf файле физически хранятся данные базы.
*.ndf – вторичные файлы данных базы, которые также используются системой для хранения данных базы.
*.ldf – файлы журнала транзакций (лог файлы).

Каждый из указанных файлов имеет название базы данных и хранится в папке \DATA:

C:\Program Files\Microsoft SQL Server\Название_Базы_Данных\MSSQL\DATA

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

Причины утери данных MSSQL

Чтобы правильно подобрать способы восстановления базы данных и методы её резервирования, необходимо понимать, что может послужить причиной утери таких данных. Причин может быть множество, но основными можно назвать следующие:

Ошибки программного обеспечения . Это как правило логические ошибки или сбой системы. В результате возникновения таких ошибок система произвольно осуществляет аварийное завершение работы системы, после чего не может выполнить восстановление.

Сбой или выход из строя аппаратного обеспечения . Наиболее частой причиной утери данных базы данных по причине аппаратного обеспечения, является выход из строя дискового накопителя (жесткого диска). Но утерей данных или базы Microsoft SQL Server может также обернутся выход из строя компьютера по любой из причин, во время работы базы данных.

Человеческий фактор . Утеря данных в результате неумышленных действий пользователя или администратора системы.

Способы восстановления базы данных

Есть несколько способов резервирования и восстановления данных базы SQL Server. Использование каждого из них зависит от преследуемой цели: плановое создание бэкапа базы данных или восстановление из него при переносе базы данных на другую машину, или необходимость восстановления данных базы MSSQL в результате её утери или удаления.

Создать копию базы данных для дальнейшего восстановления можно как с помощью встроенных в Microsoft SQL Server Management Studio инструментов, так и вручную. Создание и восстановление базы данных из созданной вручную копии, это более быстрый процесс чем создание и разворачивание резервной копии, но не такой надёжный.

Кроме того, если скопировать файлы базы данных вручную не остановив её или во время транзакции, то такие файлы сохранятся в несогласованном состоянии, что приведёт к ошибкам при попытке восстановить систему с их помощью. Поэтому прежде чем создавать копию файлов MSSQL вручную (файлов данных и журналов транзакций) для бэкапа, базу данных необходимо отключить (перевести в offline режим).

Читайте также: