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

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

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

Типы восстановления

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

В Microsoft SQL Server используются следующие базовые типы восстановления:

• восстановление базы данных;
• восстановление журналов регистрации транзакций;
• восстановление файлов и групп файлов;
• восстановление страниц.

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

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

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

Чтобы восстановить базу данных, требуется по крайней мере один резервный файл, и это должен быть файл с полной резервной копией. При использовании одного резервного файла, если процесс пройдет нормально, вы получите базу данных, приведенную к состоянию на момент формирования этой резервной копии. Это будет копия базы данных в указанный момент за вычетом неподтвержденных транзакций. Восстановление баз данных — общепринятый метод перемещения копий баз данных с сервера на сервер для выполнения таких операций, как тестирование и диагностика; при этом размеры базы данных не должны превышать разумные пределы («разумные пределы» предполагают практическую возможность работы с базой данных с учетом ограничений по времени и объему дискового пространства, необходимого для ее перемещения).

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

Базовая резервная копия подготовит вашу платформу к процессу восстановления. Здесь вы можете остановиться, если для удовлетворения ваших потребностей в деле восстановления вам не нужно будет использовать последующие резервные копии. Если же вам нужно двигаться в сторону восстановления на определенный момент, то в вашем распоряжении набор разностных резервных копий и копий журнала регистрации транзакций. Как отмечалось в предыдущей статье, в разностные копии включаются все страницы базы данных, измененные с момента получения последней полной резервной копии. Это означает, что если полные резервные копии формируются у вас по понедельникам в полдень, а разностные резервные копии — в 11 часов утра ежедневно, то размеры каждой последующей разностной копии будут увеличиваться до полудня следующего понедельника, когда будет создана очередная полная резервная копия. Я исхожу из того, что работа с базой данных осуществляется на регулярной основе и что в ходе этой работы либо модифицируются данные с помощью операторов INSERT, UPDATE или DELETE, либо изменяется структура объектов, входящих в базу данных. При таком графике, если у вас происходит сбой в среду в 13:00, вы первым делом восстановите полную резервную копию, полученную в понедельник, а затем разностную резервную копию от среды. Далее вы примените резервные копии журнала регистрации транзакций с этого момента, с тем чтобы привести базу данных к состоянию на момент, предшествующий 13:00. Надеюсь, вы резервируете журналы регистрации транзакций, если для вас важно иметь возможность восстановления по этой схеме?

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

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

Восстановление, без восстановления, ожидание

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

1. Восстановление

Когда база данных находится в восстановленном состоянии, это означает, что она готова к работе и у вас нет возможности восстанавливать дополнительные копии с целью сдвинуть состояние базы далее по оси времени. Чтобы выполнить цепочку операций по восстановлению, вы не можете нарушить зафиксированную в журнале последовательность транзакций, которые изменяли эту базу. Данную журнальную последовательность можно представить как историю базы данных. При регистрации каждой транзакции присваивается специальный номер, log sequence number (LSN). В режиме восстановления с протоколированием при восстановлении полных, разностных резервных копий, а также резервных копий журнала регистрации транзакций эти резервные копии должны быть упорядочены и применены таким образом, чтобы порядок номеров LSN не нарушался. Если бы вы позволили базе данных перейти в состояние восстановления и пользователи начали бы выполнять новые транзакции с использованием объектов этой базы данных, вы не смогли бы в дальнейшем применять резервные копии, поскольку в такой ситуации цепочка была бы разорвана новыми транзакциями, получающими новые номера LSN. Чтобы перевести базу данных в восстановленное состояние в конце процесса восстановления, нужно использовать ключевое слово RECOVERY в предложении WITH команды на восстановление. Синтаксис мы рассмотрим в конце статьи.

2. Без восстановления

Если база данных приведена в состояние восстановления, это отображается в обозревателе объектов среды SQL Server Management Studio. Это означает, что база данных находится в состоянии, в котором по крайней мере один резервный файл был восстановлен и база данных готова принять следующую резервную копию в цепочке, будь то разностная резервная копия или резервная копия журнала регистрации транзакций. Кроме того, это может означать, что пользователь, восстанавливавший последнюю резервную копию, не привел базу данных в состояние восстановления с помощью упомянутого выше ключевого слова RECOVERY. База данных в состоянии восстановления может принимать последующие резервные файлы в процессе восстановления, но не может санкционировать какие-либо действия над собой со стороны конечных пользователей, включая даже операции считывания, которые никоим образом не изменяют данные. Если база данных пребывала в восстановленном состоянии, ее нельзя привести в состояние восстановления, в котором она будет принимать новые действия в процессе восстановления, по причинам, изложенным выше. Если вы хотите, чтобы база данных в процессе восстановления могла принимать дополнительные разностные резервные копии или резервные копии журналов регистрации транзакций, проследите за тем, чтобы в предложение WITH команды восстановления было включено ключевое слово NO_RECOVERY.

3. Ожидание

База данных в режиме ожидания пребывает в состоянии неопределенности: она допускает выполнение пользователями операций чтения, а если ее чуть-чуть «подтолкнуть» к этому, может предпринимать дополнительные действия по восстановлению. Чтобы гарантировать такую возможность, а также обеспечить стабильное и единообразное состояние данных для работы с запросами, база данных должна отменить все незавершенные транзакции. Если бы она отменила эти транзакции, вы не смогли бы восстанавливать последующие резервные копии, поскольку цепочка номеров LSN была бы разорвана. Так вот, в этих условиях SQL Server сохраняет упомянутые незавершенные транзакции в файле UNDO. Прежде чем приступать к восстановлению последующих журналов регистрации транзакций, SQL Server придется привести базу данных в состояние восстановления, применить хранимые в файле UNDO транзакции и затем, наконец, восстановить следующий журнал регистрации транзакций в цепочке резервирования. Чтобы привести базу данных в состояние ожидания, необходимо ввести в предложение WITH инструкции восстановления ключевое слово STANDBY, а также указать путь к файлу UNDO.

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

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

История резервирования тестовой базы данных

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

Экран 1. История резервирования тестовой базы данных

Кроме того, мы узнаем, что кто-то удалил некую весьма важную таблицу в 20:26 30 августа 2016 года с помощью следующей команды:

DROP TABLE Very_Important_Table;

Процесс восстановления: процесс ГИП — T-SQL

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

Формы восстановления размещаются по щелчку правой кнопкой мыши на базе данных, которую вы хотите восстановить. Далее перемещайтесь по последующим всплывающим меню, пока не дойдете до разных типов восстановления, которые можете использовать (см. экран 2).

Экран 2. Выбор типа восстановления

В данном примере нам нужно использовать восстановление базы данных. Когда на экране отобразится форма Restore Database, в ней будут заполнены необходимые значения, позволяющие вам дойти до позднейшей точки восстановления, на которую могут вывести ваши резервные копии на базе сохраненной истории резервирования. В данном случае мы начинаем с последней полной резервной копии, последней разностной копии, сформированной до момента, который SQL Server считает вашей точкой восстановления — последним моментом времени, до которого возможно восстановление; далее следуют журналы регистрации транзакций, которые помогут вам добраться до этого момента (см. экран 3).

Экран 3. Восстановление базы данных

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

На экране появляется форма, подобная той, что вы видите на экране 4, для SQL Server Management Studio 2016. Единственное различие состоит в том, что в вашей форме будет выбрана настройка Last backup taken. Я же сделал еще один шаг: указал момент времени, по состоянию на который необходимо восстановить базу данных.

Экран 4. Указание периода времени для восстановления базы данных

Если теперь я нажму кнопку ОК, мы воссоединимся с остальными читателями на странице Files (см. экран 5). Эта страница используется для того, чтобы дать вам возможность осуществить восстановление в другом месте. Данная возможность пригодится в тех случаях, когда возникает необходимость восстановить копию базы данных на другом сервере и, возможно, с другой файловой структурой. Когда дело дойдет до синтаксиса, к базовому коду нужно будет добавить оператор MOVE, как мы увидим позже. Поскольку в данный момент происходит восстановление существующей базы данных, здесь мы не будем вносить изменения.

Экран 5. Указание места для восстановления базы данных

Наконец, мы переходим на страницу Options. В нашем примере я внес соответствующие изменения, но каждое из них разъясняется ниже (см. экран 6).

Экран 6. Дополнительные параметры для восстановления

Варианты восстановления

Эти варианты определяют, что произойдет с нашей базой данных по завершении процесса восстановления.

• Overwrite the existing database («Записать поверх существующей базы данных»). Мы делаем такой выбор, так как нам нужно заменить испорченный кем-то текст. В этом случае мы потеряем все транзакции, совершенные с того момента, к которому вы должны привести базу данных в восстановленном состоянии.
• Если бы мы имели дело с базой данных в процессе репликации, нам следовало бы рассмотреть вариант Preserve the replication settings («Сохранить настройки репликации») с целью сохранения возможности возвращения базы данных в нашу схему репликации.
• Настройка Restrict access to the restricted database («Ограничить доступ к защищенной базе данных») заблокирует возможность общего доступа к базе данных. Ее можно использовать для восстановления и последующей диагностики базы данных без предоставления пользователям права работать с ней.

Состояние восстановления

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

Резервирование остатка журнала

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

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

Теперь мы готовы привести базу данных к состоянию на тот момент восстановления, который был указан. Но перед тем как мы это сделаем, я хочу показать вам код, который будет выполнять данный процесс. Почти во всех диалоговых окнах SQL Server Management Studio предусмотрена возможность в фоновом режиме записывать в виде сценария выполняемые действия в новое окно запроса, в буфер обмена или в задание агента SQL Server, с тем чтобы выполнить их позднее. Если я переведу запись в новое окно запроса и подчищу сценарий, чтобы окно выглядело более презентабельно, вы сможете увидеть все шаги, отраженные в коде. Они представлены в листинге 1 (примечания мои: понятно, что SQL — язык хороший, но не настолько).

Обратите внимание на то, что в сгенерированном коде имеется два параметра, применяемых только при использовании ленты: NOUNLOAD и NOREWIND. При выполнении операций, не предусматривающих использование ленты, они игнорируются, но тем не менее генерируются по умолчанию. Их можно игнорировать. NOSKIP, как вы увидите в резервной копии остатка журнала, определяет, следует ли в ходе операции резервирования перед началом записи поверх другой информации осуществлять проверку истечения срока действия резервных копий на различных носителях записи. Здесь этот параметр тоже добавляется по умолчанию и может быть проигнорирован.

Как мы видим из кода, база данных будет переведена в однопользовательский режим, при этом все сеансы, предусматривающие подключение к базе данных, будут разорваны, а незавершенные транзакции будут подвергнуты процедуре отмены. Это даст возможность сформировать финальную резервную копию журнала регистрации транзакций, сохраняющую состояние базы данных непосредственно перед ее перезаписью как часть процесса восстановления. По завершении формирования резервной копии остатка журнала мы проходим через процессы полного, разностного восстановления и восстановления журнала. После окончания каждого процесса база данных остается в состоянии без восстановления, norecovery; таким образом обеспечивается возможность выполнения следующей операции восстановления. Наконец, мы переходим к резервной копии журнала регистрации транзакций, где указывается момент времени, на который мы хотим восстановить данные. С помощью команды STOPAT мы можем задать условие, при котором процесс не будет воспроизводить транзакции, совершенные после указанного момента. Возможно, вы обратили внимание и на то, что здесь также происходит восстановление с параметром WITH RECOVERY, исключающее возможность выполнения новых операций по восстановлению. Наконец, мы выводим базу данных из однопользовательского режима, что позволяет всем пользователям вернуться к работе с ней.

Я уже упоминал о том, что если вы захотите перенести базу данных на новое место, то можете воспользоваться настройкой WITH MOVE. Для этого нужно изменить маршрут восстановления на странице Files диалогового окна восстановления. Такое изменение окажет влияние только на первый этап процесса — на процедуру восстановления полной резервной копии, так как все последующие процедуры восстановления будут обращаться непосредственно к базе данных; при этом не нужно будет ни устанавливать, ни создавать файловую структуру. Познакомьтесь с фрагментом кода в листинге 2. Я выделил его, чтобы вам было удобнее анализировать этот код.

Позвольте мне разъяснить смысл настройки STATS = 5. Эта величина показывает, какой процент восстановления фиксируется на консоли SQL Server Management Studio в ходе выполнения процесса восстановления. Присваиваемое по умолчанию значение 5 означает, что вы будете получать уведомление всякий раз по завершении очередных 5% процедуры восстановления. На мой взгляд, это слишком часто. В зависимости от размеров базы данных я обычно устанавливаю это значение в пределах от 10 до 50.

Параметр FILE

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

Простые команды резервного копирования на языке Transact-SQL

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

Резервные копии — важная составляющая процесса восстановления, но если у вас нет возможности восстановить эти копии, они попросту бесполезны. Вам часто придется слышать совет: тестируйте свои резервные копии. С помощью опубликованных в данной статье фрагментов кода вы можете с легкостью делать это. Наверняка у вас нет никакого желания попадать «на ковер» к начальству и оправдываться, что вот-де я смог получить резервные копии, но они не восстанавливались по неизвестной причине. Тестируйте резервные копии. На это уйдет какое-то время, но оно не будет потрачено зря.

USE [master]

--Переводим базу данных в режим Single_User:
ALTER DATABASE [SQL_Cruise] SET SINGLE_USER WITH ROLLBACK IMMEDIATE

--На всякий случай формируем резервную копию хвоста журнала
BACKUP LOG [SQL_Cruise]
TO  DISK = N'C:\Data\MSSQL12.MSSQLSERVER\MSSQL\Backup\SQL_Cruise_LogBackup_2016-08-30_20-37-27.bak'
WITH NOFORMAT, NOINIT,  NAME = N'SQL_Cruise_LogBackup_2016-08-30_20-37-27', NOSKIP, NOREWIND, NOUNLOAD,  STATS = 5

--Восстанавливаем первую полную резервную копию
RESTORE DATABASE [SQL_Cruise]
FROM  DISK = N'C:\temp\SQL_Cruise_FULL.bak'
WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  REPLACE,  STATS = 5

--Восстанавливаем позднейшую разностную резервную копию из возможных, соответствующую нашей цели:
RESTORE DATABASE [SQL_Cruise]
FROM  DISK = N'C:\temp\SQL_Cruise_DIFF_3.bak'
WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5

--Восстанавливаем полные резервные копии журнала регистрации транзакций в порядке:
RESTORE LOG [SQL_Cruise]
FROM  DISK = N'C:\temp\SQL_Cruise_log_03.trn'
WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5

RESTORE LOG [SQL_Cruise]
FROM  DISK = N'C:\temp\SQL_Cruise_log_04.trn'
WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 5

--Восстанавливаем последнюю резервную копию журнала регистрации транзакций, включающую момент времени и восстановление:
RESTORE LOG [SQL_Cruise]
FROM  DISK = N'C:\temp\SQL_Cruise_log_05.trn'
WITH  FILE = 1,  RECOVERY, NOUNLOAD,  STATS = 5,
        STOPAT = N’2016-08-30T20:26:00’

--Выводим базу данных из режима single_user:
ALTER DATABASE [SQL_Cruise] SET MULTI_USER
GO

RESTORE DATABASE [SQL_Cruise] FROM  DISK = N'C:\temp\SQL_Cruise_FULL.bak'
WITH  FILE = 1,
        MOVE N'SQL_Cruise'
                TO N'C:\Data\MSSQL12.MSSQLSERVER\MSSQL\DATA\SQL_Cruise_NEW.mdf',
        MOVE N'SQL_Cruise_log'
                TO N'C:\Data\MSSQL12.MSSQLSERVER\MSSQL\DATA\SQL_Cruise_NEW_log.ldf',
        NORECOVERY,  NOUNLOAD,  REPLACE,  STATS = 5

STATS

Резервирование остатка журнала

--Переводим базу данных в режим Single_User:
ALTER DATABASE [] SET SINGLE_USER WITH ROLLBACK IMMEDIATE

--На всякий случай выполняем резервную копию хвоста журнала:
BACKUP LOG []
TO  DISK = N''
WITH NOFORMAT, NOINIT,  NAME = N'', STATS = 

Восстанавливаем полную или разностную резервную копию в том же месте
(синтаксис тот же)

RESTORE DATABASE []
FROM  DISK = N''
WITH  FILE = ,  ,  ,  STATS = 

Восстанавливаем полную резервную копию на новом месте

RESTORE DATABASE []
FROM  DISK = N''
WITH  FILE = ,
        MOVE N''
                TO N'',
        MOVE N''
                TO N'',
        ,  ,  STATS = 

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

RESTORE LOG []
FROM  DISK = N''
WITH  FILE = ,  ,  ,  STATS = 

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

RESTORE LOG []
FROM  DISK = N''
WITH  FILE = ,  ,  ,  STATS = 
        STOPAT = N''