Как восстановить базу sql из z 7

Полное восстановление базы данных (простая модель восстановления)

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

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

Не рекомендуется подключать или восстанавливать базы данных, полученные из неизвестных или ненадежных источников. Эти базы данных могут содержать вредоносный код, который может выполнять непреднамеренный код Transact-SQL или вызвать ошибки, изменив схему или физическую структуру базы данных. Перед тем как использовать базу данных, полученную из неизвестного или ненадежного источника, выполните на тестовом сервере инструкцию DBCC CHECKDB для этой базы данных, а также изучите исходный код в базе данных, например хранимые процедуры и другой пользовательский код.

В этом разделе.

• Общие сведения о восстановлении баз данных в рамках простой модели восстановления
• Связанные задачи

Сведения о поддержке резервных копий более ранних версий SQL Server см. в подразделе «Поддержка совместимости» раздела RESTORE (Transact-SQL).

Общие сведения о восстановлении баз данных в рамках простой модели восстановления

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

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

Если база данных восстанавливается на другой экземпляр сервера, см. раздел Копирование баз данных путем создания и восстановления резервных копий.

Базовый синтаксис инструкции Transact-SQL RESTORE

Базовый синтаксис Transact-SQLRESTORE для восстановления полной резервной копии базы данных:

RESTORE DATABASE имя_базы_данных FROM устройство_резервного_копирования [ WITH NORECOVERY ]

Если планируется также восстановление разностной резервной копии базы данных, используйте параметр WITH NORECOVERY.

Базовый синтаксис инструкции RESTORE восстановления из резервной копии базы данных:

RESTORE DATABASE имя_базы_данных FROM устройство_резервного_копирования WITH RECOVERY

Пример (Transact-SQL)

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

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

Пример начинается с инструкции ALTER DATABASE , которая устанавливает модель восстановления SIMPLE .

USE master; --Make sure the database is using the simple recovery model. ALTER DATABASE AdventureWorks2022 SET RECOVERY SIMPLE; GO -- Back up the full AdventureWorks2022 database. BACKUP DATABASE AdventureWorks2022 TO DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak' WITH FORMAT; GO --Create a differential database backup. BACKUP DATABASE AdventureWorks2022 TO DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak' WITH DIFFERENTIAL; GO --Restore the full database backup (from backup set 1). RESTORE DATABASE AdventureWorks2022 FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak' WITH FILE=1, NORECOVERY; --Restore the differential backup (from backup set 2). RESTORE DATABASE AdventureWorks2022 FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak' WITH FILE=2, RECOVERY; GO 

Связанные задачи

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

• Восстановление резервной копии базы данных в простой модели восстановления (Transact-SQL)
• Restore a Database Backup Using SSMS
• Восстановление базы данных в новое расположение (SQL Server)

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

Восстановление резервной копии с помощью управляющих объектов SQL Server (SMO)

Полное восстановление базы данных (модель полного восстановления)

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

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

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

Ненадежные источники

Не рекомендуется подключать или восстанавливать базы данных, полученные из неизвестных или ненадежных источников. Эти базы данных могут содержать вредоносный код, который может выполнять непреднамеренный код Transact-SQL или вызвать ошибки, изменив схему или физическую структуру базы данных. Перед тем как использовать базу данных, полученную из ненадежного источника, выполните для нее инструкцию DBCC CHECKDB на тестовом сервере. Также изучите содержащийся в ней код, написанный пользователем: хранимые процедуры и другой пользовательский код.

Резервные копии из предыдущих версий

Сведения о поддержке резервных копий более ранних версий SQL Server см. в подразделе «Поддержка совместимости» раздела RESTORE (Transact-SQL).

Восстановление базы данных до точки сбоя

Обычно восстановление базы данных до точки сбоя включает следующие основные шаги:

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

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

На следующем рисунке показана эта последовательность восстановления. После сбоя (1) создается резервная копия заключительного фрагмента журнала (2). Затем база данных восстанавливается до точки сбоя. Это включает восстановление резервной копии базы данных, последующей разностной резервной копии и всех резервных копий журналов, сохраненных после разностной резервной копии, в том числе резервной копии заключительного фрагмента журнала.

Если база данных восстанавливается на другой экземпляр сервера, см. раздел Копирование баз данных путем создания и восстановления резервных копий.

Базовый синтаксис инструкции Transact-SQL RESTORE

Базовый синтаксис RESTORETransact-SQL для последовательности восстановления на предыдущем рисунке выглядит следующим образом:

1. RESTORE DATABASE база_данных FROM full database backup WITH NORECOVERY;
2. RESTORE DATABASE база_данных FROM полная_разностная_резервная_копия WITH NORECOVERY;
3. RESTORE LOG база_данных FROM резервная_копия_журнала WITH NORECOVERY; Повторите шаг по восстановлению журнала из резервной копии для каждой резервной копии журнала.
4. RESTORE DATABASE база_данных WITH RECOVERY;

Пример. Восстановление до точки сбоя (Transact-SQL)

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

В этом примере используется резервное копирование базы данных и резервное копирование журналов, созданное в разделе «Использование резервных копий базы данных в модели полного восстановления» в разделе «Полные резервные копии базы данных ( SQL Server)». До создания резервной копии базы данных образец базы данных AdventureWorks2022 был настроен на использование модели полного восстановления.

USE master; --Create tail-log backup. BACKUP LOG AdventureWorks2022 TO DISK = 'Z:\SQLServerBackups\AdventureWorksFullRM.bak' WITH NORECOVERY; GO --Restore the full database backup (from backup set 1). RESTORE DATABASE AdventureWorks2022 FROM DISK = 'Z:\SQLServerBackups\AdventureWorksFullRM.bak' WITH FILE=1, NORECOVERY; --Restore the regular log backup (from backup set 2). RESTORE LOG AdventureWorks2022 FROM DISK = 'Z:\SQLServerBackups\AdventureWorksFullRM.bak' WITH FILE=2, NORECOVERY; --Restore the tail-log backup (from backup set 3). RESTORE LOG AdventureWorks2022 FROM DISK = 'Z:\SQLServerBackups\AdventureWorksFullRM.bak' WITH FILE=3, NORECOVERY; GO --recover the database: RESTORE DATABASE AdventureWorks2022 WITH RECOVERY; GO 

Восстановление базы данных на момент времени в пределах резервной копии журнала

При работе в режиме полного восстановления можно провести полное восстановление базы данных до состояния на момент времени, до помеченной транзакции или до номера LSN в резервной копии журнала. Однако в модели восстановления с неполным протоколированием, если в резервной копии журнала содержатся изменения с неполным протоколированием, восстановление до момента времени невозможно.

Образцы сценариев восстановления на определенный момент времени

В следующем примере предполагается использование критически важной системы баз данных, в которой полная резервная копия баз данных создается ежедневно в полночь, разностная резервная копия — каждый час, с понедельника до субботы. Резервные копии журнала создаются каждые 10 минут в течение дня. Чтобы восстановить базу данных в состоянии, находится в 5:19 утра в среду, сделайте следующее:

1. Восстановить полную резервную копию базы данных, полученную в полночь вторника.
2. Восстановите разностную резервную копию базы данных, созданную в среду в 5:00.
3. Примените резервную копию журнала транзакций, созданную в среду в 5:10.
4. Примените резервную копию журнала транзакций, созданную 5:20 утра в среду, указав, что процесс восстановления применяется только к транзакциям, которые произошли до 5:19 утра.

Кроме того, если база данных должна быть восстановлена в своем состоянии в 3:04 В четверг, но разностная резервная копия базы данных, созданная в 3:00 в четверг, недоступна, сделайте следующее:

1. Восстановить резервную копию базы данных, полученную в полночь в среду.
2. Восстановите разностную резервную копию базы данных, созданную в четверг в 2:00.
3. Примените все резервные копии журнала транзакций, созданные с 2:10 утра до 3:00 в четверг.
4. Примените резервную копию журнала транзакций, созданную в 3:10 утра в четверг, остановив процесс восстановления в 3:04 утра.

Связанные задачи

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

• Restore a Database Backup Using SSMS
• Восстановление базы данных в новое расположение (SQL Server)

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

Восстановление резервной копии журнала транзакций

Восстановление резервной копии с помощью управляющих объектов SQL Server (SMO)

Восстановление базы данных до точки в резервной копии журнала

• Восстановление базы данных SQL Server до определенного момента времени (модель полного восстановления)
• Восстановление связанных баз данных, которые содержат помеченную транзакцию
• Восстановление до регистрационного номера транзакции в журнале (SQL Server)

Резервное копирование и восстановление базы данных в MS SQL Server

26.02.2020

insci

SQL Server

комментариев 16

В этой статье мы рассмотрим, как настроить резервное копирование баз данных в Microsoft SQL Server, покажем, как восстановить базу данных из резервной копии с помощью SQL Server Management Studio и Transact-SQL. Первая часть статьи посвящена теоретическим аспектам резервного копирование в SQL, во второй на примере мы покажем, как настроить регулярное резервное копирование базы данных MS SQL с помощью плана обслуживания и восстановить базу из резервной копии на примере установленного Microsoft SQL Server 2019.

Требования к плану резервного копирования баз данных SQL Server устанавливает бизнес, учитывая несколько критериев:

Допустимый объём потерянных данных (за последний день/час/минуту/секунду);

Следует понимать, что с помощью механизмов резервного копирования невозможно добиться резервирования данных в реальном времени. Для этой цели используются другие технологии высокой доступности SQL Server – группы доступности Always On, зеркалирование баз данных или репликация.

Типы резервного копирования SQL Server

Полное (Full Backup)

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

Полную резервную копию вы можете восстановить за 1 шаг, так как она не требует других дифференциальных/инкрементальных копий.

Если модель восстановления базы SQL данных установлена как “Полная”, то при восстановлении бекапа вы можете указать параметр “STOPAT”, где указывается время (до секунды) на котором нужно остановить восстановление данных. Например, сотрудник внёс некорректные данные в 14:46:07, с помощью параметра STOPAT вы можете восстановить данные на момент 14:46:06

Дифференциальное

Дифференциальное или разностное резервное копирование — это копирование только тех данных, которые появились с момента последней полной резервной копии.

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

Обычно при использовании разностного резервного копирования используют план по типу “полное раз в N дней, дифференциальное каждые N часов”. Если ежедневный оборот данных достаточно высокий, то данный тип резервных копий может быть неудобен в применении, так как копии будут весить довольно много.

Например, если полная резервная копия весит 300 GB, а дифференциальная спустя час работы 5 GB, то спустя сутки это будет 120 GB, что делает использование данного типа копий нерациональным.

Журнал транзакций

Резервное копирования журнала транзакций копирует все транзакции, которые произошли с момента последнего резервного копирования, а затем урезает журнал транзакций для освобождения дискового пространства.

Восстанавливая журнал транзакций, вы также можете указать параметр STOPAT, как и в восстановлении полной резервной копии.

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

Tail-Log

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

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

Copy-only

Этот вид бекапа не может служить “базой” для дифференциальных резервных копий и для копий журнала транзакций. Copy-only бекап не нарушает текущую цепочку резервных копий (полный-> дифференциальный или полный -> копии журналов транзакций) и используется только в том случае, если вам нужно снять полную резервную копию, не задевая текущую цепочку бекапов.

За исключением этих нюансов – ничем не отличается от обычной полной копии.

Частичная резервная копия

Partial backup этот тип резервной копии используется для того, чтобы снять копии с read-only файловых групп. На практике используется редко.

Резервное копирование файлов и файловых групп

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

Модели восстановления базы данных SQL Server

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

Простая модель восстановления

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

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

При использовании этой модели восстановления, следующий функционал SQL Server недоступен:

• Доставка журналов транзакций
• Always On
• Point-In-Time восстановление
• Резервные копии журнала транзакций

Полная модель восстановления

Полная модель восстановления хранит все транзакции в журнале транзакций до усечения журнала (посредством снятия резервной копии журнала).

Это самая “надежная” модель восстановления, при аварийном сбое можно вы сможете восстановить все транзакции, кроме тех, которые не успели завершиться при аварии.

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

Восстановление с неполным протоколированием (bulk logged)

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

• SELECT INTO
• BULK INSERT и BCP
• INSERT INTO SELECT
• Операции с индексами (CREATE INDEX, ALTER INDEX REBUILD, DROP INDEX)

В остальном эта модель работает аналогично полной модели восстановления.

Настройка резервного копирования SQL Server с помощью плана обслуживания

Планы обслуживания SQL Server это самый распространенный способ настройки регулярного резервного копирования.

Рассмотрим настройку резервного базы данных на SQL Server копирования по плану:

• Полная резервная копия каждые 24 часа
• Копия журнала транзакций – каждые 30 минут

В SSMS (SQL Server Management Studio) перейдите в раздел Management -> Maintenance Planes и запустите -> мастер создания плана обслуживания (Maintenance Plan Wizard).

Укажите имя плана и выберите режим “Separate schedules for each task”.

Выберите операции, которые нужно сделать в этом плане обслуживания:

• Back Up Database (Full)
• Back Up Database (Transaction Log)

Используйте следующую последовательность операций:

Выберите базу данных SQL Server, которую нужно бэкапить и выберите расписание.

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

Укажите сколько будут храниться резервные копии (например, 14 дней).

Нажмите Next и аналогично создайте расписание резервного копирования для журнала транзакций.

Опционально можно указать файл для ведения лога плана обслуживания.

Завершение настройки плана обслуживания SQL Server.

Выполните план обслуживания вручную и проверьте журнал.

Как вы видите была создана полная резервная копия базы данных SQL Server и следом копия журнала транзакций. На этом настройка резервного копирования закончена.

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

Теперь рассмотрим, как восстановить базы данных SQL Server из резервной копии. Для восстановления базы можно использовать графическую консоль SQL Server Management Studio или язык T-SQL.

Восстановление резервной копии с помощью SQL Server Management Studio

Запустите SSMS, щелкните по разделу Database и выберите пункт Restore Database.

Выберите базу данных. В окне появится список резервных копий, зарегистрированных в SQL Server для этой базы данных.

Для примера, воспользуемся Point-In-Time восстановлением и выберем момент, на который мы хотим восстановить базу данных. Нажмите Timeline.

Выберите опцию “Close existing connections to destination database”, если ваша база данных находится в статус Online

Нажмите ОК. После этого база данных восстановится на выбранный момент времени.

Восстановление базы данных MS SQL Server с помощью T-SQL

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

USE [master]
ALTER DATABASE [TestDatabase2] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
BACKUP LOG [TestDatabase2] TO DISK = N’E:\MSSQL15.NODE2\MSSQL\Backup\TestDatabase2_LogBackup_2020-02-17_15-39-43.bak’ WITH NOFORMAT, NOINIT, NAME = N’TestDatabase2_LogBackup_2020-02-17_15-39-43′, NOSKIP, NOREWIND, NOUNLOAD, NORECOVERY, STATS = 5
RESTORE DATABASE [TestDatabase2] FROM DISK = N’E:\MSSQL15.NODE2\MSSQL\Backup\full.bak’ WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5
RESTORE LOG [TestDatabase2] FROM DISK = N’E:\MSSQL15.NODE2\MSSQL\Backup\trans.bak’ WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5
RESTORE LOG [TestDatabase2] FROM DISK = N’E:\MSSQL15.NODE2\MSSQL\Backup\trans.bak’ WITH FILE = 2, NOUNLOAD, STATS = 5, STOPAT = N’2020-02-17T15:38:23′
ALTER DATABASE [TestDatabase2] SET MULTI_USER
GO

В данном случае база данных переводится в SINGLE_USER, но нужно быть аккуратным с этим параметром, так как в некоторых ситуациях вы можете закрыть себе доступ, если кто-то откроет сессию раньше вас.

Дальше выполняется tail-log бекап, затем восстанавливается полный бекап и следом восстанавливаются бекапы журнала транзакций. Обратите внимание на параметр STOPAT, база данных восстановиться на момент 15:38:23

Рекомендации и best practice по резервному копированию SQL Server

• Резервные копии не должны храниться на том же диске, что и ваш SQL Server. Это правило касается любых резервных копий. При выходе из строя основного дискового массива вы должны иметь доступ к вашим резервным копиям. Если позволяют ресурсы, лучше хранить резервные копии сразу на нескольких разрозненных массивах.
• Процесс резервного копирования должен минимально влиять на работу пользователей. Полные резервные копии лучше делать тогда, когда пользовательская активность на сервере минимальна.
• Регулярно проверяйте целостность резервных копий и проводите тестовые восстановления. Вы всегда должны быть уверены, что ваши бекапы валидны и готовы к восстановлению в любое время.
• Заранее рассчитайте время, необходимое для полного восстановления при аварии. Часто в базах хранится критически важная для бизнеса информация, поэтому ваш руководитель должен знать минимальное время, которое потребуется для восстановления после аварии. Если даже вас об этом не спрашивают, лучше заранее уведомить об этом, чтобы в случае аварии не возникло недопонимания.

Предыдущая статья Следующая статья

Как проверить базу данных на наличие ошибок?

В общем-то вопрос в названии темы. В РМК как-то странно начали считаться деньги в кассе. Сформировал в Журнале событий ошибки, там были предупреждения, о необходимости проверить базу данных.

8 Комментарии
Сортировка: Стандарт | Новые | Голоса
Danil написал 28 октября 2019

Подозреваете, что база физически имеет ошибки? У вас вроде MSSQL он достаточно надежен в этом плане, хотя и на старуху бывает проруха. Давайте сначала попробуем понять, что у вас пошло не так.

В РМК как-то странно начали считаться деньги в кассе.

Можно подробнее? Что смущает?

Сформировал в Журнале событий ошибки, там были предупреждения, о необходимости проверить базу данных.

Текст события скиньте пожалуйста.

berivan написал 28 октября 2019

Отработали день, а z-отчет прошел с 0 суммой, нет информации ни о продажах, ни о деньгах — все по 0. На следующий день, деньги в кассе совсем не сходились с тем, что должно быть.

Текст события скиньте пожалуйста.

SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: неправильная контрольная сумма (ожидаемая: 0xd4ced154; фактическая: 0xee2564a6). Она произошла при прочитать страницы (1:2152) в базе данных с идентификатором 4 по смещению 0x000000010d0000 файла «D:\SanSan\DATA\MSSQL12.SQLEXPRESS\MSSQL\DATA\MSDBData.mdf». Дополнительные сведения см. в журнале ошибок SQL Server и журнале системных событий. Это серьезная ошибка, которая угрожает целостности базы данных и должна быть немедленно исправлена. Выполните полную проверку базы данных на согласованность (DBCC CHECKDB). Эта ошибка может быть вызвана многими причинами; дополнительные сведения см. в электронной документации по SQL Server.

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

Обработано 1608 страниц для базы данных «SanSan_log», файл «SanSan3_log» для файла 1.

Обработано 2 страниц для базы данных «SanSan_log», файл «SanSan3_log_log» для файла 1.

BACKUP DATABASE успешно обработал 1610 страниц за 0.826 секунд (15.225 MБ/сек).

Выполнение данной инструкции было прервано.