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

Я выступал на конференции IT/Dev Connections 2016 с докладом на тему «О чем должен знать каждый сотрудник, администрирующий базы данных по совместительству». Примечательно, что перечень необходимых знаний практически бесконечен — одно считается важным для администратора базы данных, едва начинающего свою профессиональную карьеру, и совсем другое — для специалиста, который уже является состоявшимся администратором баз данных и движется по пути к званию старшего администратора.

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

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

Типы резервных копий

В системе Microsoft SQL Server выполняются три базовых типа резервных копий:

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

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

Полные резервные копии

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

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

Разностные резервные копии

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

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

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

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

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

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

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

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

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

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

  • Full (режим полного восстановления);
  • Simple (простая модель восстановления);
  • Bulk-Logged (режим неполного восстановления).

Режим полного восстановления

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

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

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

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

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

Режим неполного восстановления

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

К числу этих в минимальной степени регистрируемых (также именуемых нерегистрируемыми) процессов относятся:

  • операции по перестроению, созданию, обновлению индексов;
  • команды WRITETEXT и UPDATE­TEXT (нерекомендованные к применению);
  • INSERT… INTO;
  • SELECT… INTO;
  • процессы массовой загрузки (Bulk loading processes) с помощью команд BCP.

Введение в журналы транзакций в SQL Server

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

Журнал регистрации транзакций в базе данных SQL Server позволяет фиксировать транзакции, которые либо модифицируют данные, либо изменяют структуру базы данных. В этих типах транзакций используются запросы на языке модификации данных, data modification language (DML), или языке определения данных, data definition language (DDL) соответственно. Отсюда следует, что запросы, предполагающие считывание данных, скажем, запросы SELECT на языке Transact-SQL, не будут регистрироваться в журнале транзакций, поскольку, в отличие от запросов INSERT, UPDATE и DELETE, они не изменяют значения данных. Это запросы на языке DML: в запросах такого типа администратор изменяет значения данных. Запросы DDL так или иначе изменяют определение данных или их структуру: так, в процессе перестройки индексов изменяется структура индекса для таблицы, а следовательно, изменяются и метаданные — данные, описывающие другие данные. Еще один пример запроса DDL, который будет регистрироваться: запрос, меняющий тип данных в столбце таблицы с целочисленного на строковый.

Эффект режима восстановления и журнал транзакций

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

Как сокращается и растет журнал транзакций

Операции записи в журнал транзакций (для обработки транзакций в файлах данных) и считывания данных из этого журнала (в целях восстановления) осуществляются на линейной шкале времени, но в режиме «кольца»: в обычных обстоятельствах, когда процесс доходит до конца физического файла, он возвращается обратно, к началу журнала транзакций. Иными словами, файл журнала регистрации вновь и вновь заполняется повторно при условии, что использованная ранее часть журнала помечается как предназначенная для повторной записи (иначе говоря, для усечения). Такое усечение неявным образом осуществляется и в режиме восстановления Simple. А вот в режимах Full и Bulk-Logged подобное усечение может быть выполнено только с помощью резервной копии журнала регистрации транзакций, в которой для этого выделяется часть журнала, сохраненная в целях восстановления. Здесь я описываю данный процесс в упрощенном виде, ибо все, что вам нужно знать об этом на начальном уровне, сводится к следующему: усечение обеспечивает возможность повторного использования журнала регистрации транзакций, и единственный способ усечения этого журнала состоит в том, чтобы воспользоваться его резервной копией. Вот почему я акцентирую внимание на необходимости формирования резервных копий журнала регистрации транзакций при работе в режимах Full и Bulk-Logged. Без усечения с помощью резервных копий журнала регистрации транзакций этот журнал никогда не будет обслуживаться по принципу карусели. Он будет постоянно прирастать с конца до тех пор, пока либо вы не сделаете резервную копию этого журнала, либо закончится дисковое пространство, выделенное для соответствующего тома. Если резервная копия журнала регистрации транзакций будет сделана, когда со времени создания предыдущей копии пройдет много времени, эта копия может получиться очень длинной. И тогда на считывание с нее данных в процессе восстановления будет уходить значительное время, а это может привести к замедлению процесса восстановления базы данных к состоянию на определенный момент. Кроме того, в ситуациях, когда бывает нужно нарастить журнал транзакций с помощью функции autogrow, администратор не сможет регистрировать новые транзакции. В сущности, любые операции с базой данных будут блокироваться до момента расширения файла на диске, поскольку зарегистрированные транзакции не смогут быть записаны в журнальный файл, и в большинстве случаев операции записи будут блокировать операции считывания в базе данных.

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

В этой статье мне хотелось бы, не слишком углубляясь, разъяснить для читателей концепцию автоматического роста (auto growth) и файловых настроек для журнала регистрации транзакций SQL Server. Вы можете иметь более одного журнала регистрации транзакций, но веских оснований для подобной настройки базы данных не существует. SQL Server не будет использовать несколько файлов журналов транзакций по принципу чередования. Система перейдет к следующему файлу, если таковой существует, и не будет «закольцовываться» на начало первого журнала до тех пор, пока не дойдет до конца последнего журнала регистрации транзакций, с учетом всех оговорок, касающихся усечения журналов. Как правило, журнал регистрации транзакций размещается на самой высокопроизводительной платформе хранения данных, отформатированной для оптимального выполнения операций записи с избыточностью для «зеркального» дублирования и чередования. Возможно, система RAID-5 будет самым экономичным вариантом, но ее использование приводит к непроизводительным затратам на операции записи четности, неоптимальным с точки зрения скорости записи. Система RAID-5 не очень подходит для форматирования дисков. Однако она сплошь и рядом используется при подготовке к работе средств хранения данных.

Что касается размеров, то я настоятельно рекомендую предусматривать для журнальных файлов полный объем дискового пространства, который, по вашим оценкам, будет израсходован на протяжении жизненного цикла базы данных. Никогда не полагайтесь на то, что в системе Microsoft SQL Server вы сможете управлять наполнением файла данными (идет ли речь о журнале регистрации транзакций или о файле данных), установив значение инкремента роста. Проблема не только в том, что в ситуации, когда в журнальном файле произойдет событие роста, все действия могут быть заблокированы. Вам придется, помимо прочего, иметь дело с физической фрагментацией. При использовании в качестве места хранения данных вращающегося диска это приведет к дополнительному снижению производительности, чего можно избежать, если с самого начала правильно оценить ситуацию и произвести настройки. В качестве страховки от блокировки всех транзакций после заполнения журнального файла я по-прежнему предлагаю настраивать журнал регистрации транзакций таким образом, чтобы значения его параметров роста отвечали следующим критериям.

  • Рост должен иметь фиксированное значение, выраженное в мегабайтах, его никогда не следует выражать в виде процента от объема журнала регистрации транзакций.
  • Значение параметра роста должно быть соразмерным вместимости базового тома.
  • Это значение должно быть таким, чтобы в случае приведения в действие оно обеспечивало быстрое выполнение во избежание продолжительных периодов блокирования всех действий, и в то же время не настолько малым, чтобы при заполнении журнального файла в нем обнаруживалось множество событий роста.

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

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

 

Проверка дискового пространства
Экран. Проверка дискового пространства

Возможно, вы обратили внимание на то, что переменная max_size_mb имеет значение NULL. Это объясняется тем, что данное значение не было задано. Теоретически оно «не ограничено», но в действительности, разумеется, ограничено объемом соответствующего тома устройства хранения.

Базовый синтаксис резервных копий SQL Server

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

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

Простое объяснение состоит в том, что если в среде SQL Server Management Studio вы запустите команду быстрого вызова Ctrl+Shift+M, на экране появится модальное окно со всеми параметрами, которые обрамляются символами «<» и «>». Кроме того, я включил команду для сжатия резервных копий. Некоторые пользователи работают с теми версиями и редакциями SQL Server, в которых сжатие не было предусмотрено. Если вы относитесь к их числу, закомментируйте эту команду перед выполнением.

Резервирование «хвоста журнала»

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

Замечания о стратегии резервирования

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

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

Листинг 1. Проверка наличия дискового пространства
SELECT DB_NAME() AS database_name,
        [name] AS [logical_file_name],
        physical_name,
        [file_type] =
                CASE type
                        WHEN 0 THEN 'Data'
                        WHEN 1 THEN 'Log'
                END,
        [size_mb] =
                CASE ceiling([size]/128)
                        WHEN 0 THEN 1
                        ELSE ceiling([size]/128)
                END,
        [available_mb] =
                CASE ceiling([size]/128)
                        WHEN 0 THEN (1 - CAST(FILEPROPERTY([name], 'SpaceUsed') as int) /128)
                        ELSE (([size]/128) - CAST(FILEPROPERTY([name], 'SpaceUsed') as int) /128)
                END,
        [growth_units]  =
                CASE [is_percent_growth]
                        WHEN 1 THEN CAST([growth] AS varchar(20)) + '%'
                        ELSE CAST([growth]/1024*8 AS varchar(20)) + 'Mb'
                END,
        [max_size_mb] =
                CASE [max_size]
                        WHEN -1 THEN NULL
                        WHEN 268435456 THEN NULL
                        ELSE [max_size]/1024*8
                END
FROM sys.database_files
ORDER BY [file_type]
        , [file_id];
Листинг 2. Базовый синтаксис резервных копий
Базовый синтаксис полной резервной копии

BACKUP DATABASE []
TO DISK = N''
WITH
        NAME = N'' + getdate(),
        ,
        STATS = 10;

Базовый синтаксис разностной резервной копии

BACKUP DATABASE []
TO DISK = N''
WITH
        DIFFERENTIAL,
        NAME = N'',
        ,
        STATS = 10;

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

BACKUP LOG []
TO DISK = N''
WITH
        NAME = N'',
        ,
        STATS = 10;
Листинг 3. Резервирование «хвоста журнала»
BACKUP LOG []
TO  DISK = N''
WITH
        NO_TRUNCATE,
        NAME = N'',
        NORECOVERY,
        STATS = 10;