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

Содержание

Резервное копирование и восстановление СУБД MySQL / Хабр

О необходимости выполнения резервного копирования для любых важных данных, будь то файлы, образ ОС или базы данных, написано множество статей. Поэтому убеждать читателя в необходимости бэкапить СУБД MySQL я не буду. Напомню лишь, что помимо бэкапа необходимо регулярно проверять резервные копии на возможность восстановления.

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

Сколько терять и за сколько восстанавливать

Итак, вспомним такие понятия как RPO и RTO.

Recovery Point Objective – максимально допустимый интервал за который мы можем позволить себе потерять данные. Например, если у нас RPO равно двум часам, то в случае сбоя мы потеряем данные максимум за последние два часа.

Recovery Time Objective — промежуток времени, в течение которого БД может оставаться недоступной в случае сбоя. То есть это то время, за которое мы обязуемся восстановить наши данные из бэкапа.

На картинке расстояние до сбоя это RPO (обычно измеряется в часах) а RTO это то расстояние-время, которое у нас останется на восстановление.

 

 Однако, RTO и RPO нельзя назвать чисто техническим понятиями, в определенной степени это характеристики, позволяющие обеспечивать непрерывность бизнес процессов. Значения величин RTO и RPO должны указываться владельцами бизнес систем, а ИТ специалисты должны в ответ выдвинуть свои требования относительно оборудования и программного обеспечения для выполнения этих требований. Например, если бизнесу необходимо, чтобы в случае аварии данные были потеряны не более чем за час, а процесс восстановления должен занимать не более 30 минут, то админы в ответ должны сказать хранилища какого размера им необходимы, с какими характеристиками по скорости работы дисков и каналов передачи данных. То есть ИТ готовит спецификацию на необходимое оборудование и ПО с ценами, бизнес посмотрев на все это пони мает, что может быть два или даже три часа простоя это не так уж и страшно, да и восстанавливаться можно подольше. В результате согласовываются новые значения RTO и RPO и стоимость спецификации снижается. Такой подход позволяет разделить ответственность между всеми сторонами. Однако очень часто присутствует другой подход к политике резервного копирования, когда ИТ сами устанавливают значения RTO и RPO и сами пытаются их выполнять без согласования с бизнесом, что является в корне неверным.

Виды бэкапов в MySQL

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

Физический бэкап предполагает создание резервных копий на файловом уровне. В простейшем случае, мы просто останавливаем базу и копируем файлы из рабочей папки (/var/lib/mysql/db/). Просто и быстро. Но не стоит забывать, что при использовании для бэкапа команд операционной системы (например cp) возможны ситуации, когда полученные после копирования файлы окажутся поврежденными и база не будет работать корректно. Такое может произойти, например при копировании в моменты высокой загрузки сервера или при копировании по сети. 

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

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

Логический бэкап лишен этих недостатков, но восстановление большой БД может занять значительное время, так как выполнение всех команд из бэкапа процесс долгий.

Альтернативным вариантом является использование сторонних средств резервного копирования, например Percona XtraBackup.

Логический бэкап

Для экспорта информации из базы данных в формате SQL можно использовать утилиту mysqldump. Вот ее синтаксис:

$ mysqldump опции имя_базы [имя_таблицы] > файл.sql

Например:

mysqldump --all-databases > dump-data. sql

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

mysqldump -h хост -P порт -u имя_пользователя -p имя_базы > data-dump.sql

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

mysql> CREATE DATABASE new_database;

shell> mysql < dump-data.sql

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

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

mysqldump -uroot -p ${DBNAME} | gzip > /tmp/${DBNAME}. sql.gz

Когда нужно не все

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

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

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

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

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

nano /etc/mysql/mysql.cnf

Укажем значение параметров log-bin, expire_log_days, max_binlog_size.

Далее перезапустим сервис.

service mysql restart

Каждая инкрементальная копия содержит изменения, которые были созданы с момента последней резервной копии, но самая первая резервная копия должна быть полной копией. Вам необходимо создать полную резервную копию через mysqldump, используя параметры —flush-log и —delete-master-logs, ––delete-master-logs удалит старые двоичные файлы журнала, а —flush-log инициализирует запись нового двоичного файла журнала. Результаты заархивируем.

mysqldump --flush-logs --delete-master-logs --single-transaction --all-databases | gzip > /var/backups/mysql/$(date +%d-%m-%Y_%H-%M-%S)-inc.gz

Мы не можем просто воспользоваться командой cp потому файлы журналов сейчас используются БД. Поэтому вам необходимо выполнить команду FLUSH BINARY LOGS, которая начнет запись в новый двоичный файл журнала. В этом случае все накопленные двоичные файлы журнала могут быть безопасно скопированы. После копирования двоичных файлов журнала они должны быть удалены, чтобы при следующем копировании они не дублировали уже созданные резервные копии данных. Для этого воспользуемся PURGE BINARY LOGS. Для автоматизации этих задач ниже приведен небольшой скрипт, который выполняет эти действия, а также помещает двоичные файлы журнала в архив.

#путь к файлу с двоичными журналами
binlogs_path=/var/log/mysql/
#путь к каталогу с бэкапами
backup_folder=/var/backups/mysql/
#создаем новый двоичный журнал
sudo mysql -E --execute='FLUSH BINARY LOGS;' mysql
#получаем список журналов
binlogs=$(sudo mysql -E --execute='SHOW BINARY LOGS;' mysql | grep Log_name | sed -e 's/Log_name://g' -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//')
#берем все, кроме последнего
binlogs_without_Last=`echo "${binlogs}" | head -n -1`
#отдельно последний, который не нужно копировать
binlog_Last=`echo "${binlogs}" | tail -n -1`
#формируем полный путь 
binlogs_fullPath=`echo "${binlogs_without_Last}" | xargs -I % echo $binlogs_path%`
#сжимаем журналы
zip $backup_folder/$(date +%d-%m-%Y_%H-%M-%S). zip $binlogs_fullPath
#удаляем сохраненные файлы журналов
echo $binlog_Last | xargs -I % sudo mysql -E --execute='PURGE BINARY LOGS TO "%";' mysql

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

cron -e

0 0 * * * sudo mysqldump --flush-logs --delete-master-logs --single-transaction --all-databases | gzip > /var/backups/mysql/full_$(date +%d-%m-%Y_%H-%M-%S).gz

*/60 * * * * sudo bash ~/scripts/скрипт_инкрментального_бэкапа

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

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

gunzip < 01-10-2020_20-08-41-full.gz

unzip \*.zip -d logs

cd logs

В отличие от полной резервной копии, созданной с помощью mysqldump, двоичные файлы журнала содержат двоичные данные. Перед их восстановлением их необходимо преобразовать в sql-выражения, и за это отвечает утилита mysqlbinlog. Эта утилита получает двоичные файлы журнала в качестве входных данных и возвращает инструкции sql. Несколько файлов можно перечислить через пробел. Не забываем о том, что порядок перечисления файлов очень важен, именно в таком порядке SQL операторы и будут выполнены.

mysqlbinlog mysql-bin.000040 mysql-bin.000059  mysql-bin.000123 | sudo mysql -u root

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

mysqlbinlog $(ls) | sudo mysql -u root

Таким образом можно снизить время, необходимое на создание бэкапов и сэкономить место для их хранения.

Заключение

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

Также напоминаю о том, что уже скоро в OTUS пройдет открытое занятие, посвященное погружению в PostgreSQL. Урок будет включать в себя:

  1. Знакомство с базой данных – особенности, немножко истории, полезность и актуальность.

  2. Способы развертывания и установки, сама установка.

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

Записаться можно на странице курса «Базы данных».

Часть 2. Настройка резервного копирования ms sql. Ошибки и заблуждения

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

Заблуждение: Зачем мне делать полный бэкап базы данных? достаточно просто скопировать файлы mdf и log!

У любой базы данных MS SQL есть как минимум два файла – данные, файл с расширением mdf, и журнал транзакций, файл с расширением log. Обрабатывая транзакции SQL Server постоянно синхронизирует информацию в этих файлах, поэтому они всегда находятся в заблокированном состоянии. Нет штатной возможности скопировать эти файлы у подключенной базы данных, даже если в ней никто не работает. Сторонние программы для бэкапирования файлов и образов также не могут скопировать эти файлы привычным образом, а фактически делают резервную копию инструкцией BACKUP DATABASE (обычно через VDI интерфейс). Часто это делается без ведома администратора, что нарушает цепочку резервных копий и является большим, неприятным, «сюрпризом» при попытке восстановления БД.

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

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

Заблуждение: для проверки созданной резервной копии достаточно выполнить команду RESTORE VERIFYONLY

Командой RESTORE VERIFYONLY можно проверить полноту резервной копии и возможность её считывания с диска. Обычно инструкция выполняется сразу после создания резервной копии. Однако необходимо знать, что команда RESTORE VERIFYONLY не проверяет структуру данных. Другими словами, успешное выполнение инструкции RESTORE VERIFYONLY не гарантирует, что реальное восстановление из резервной копии будет выполнено без ошибок. Есть только один 100% способ проверить резервные копии – попробовать восстановить из них. Поэтому рекомендуется периодически проверять резервные копии восстанавливая из них.

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

Ошибка: Создание полного бэкапа, для передачи файла на сторону, и последующее его удаление

Довольно часто приходится сталкиваться с ситуацией, когда администратор создает свежую полную резервную копию (без параметра COPY_ONLY), чтобы передать её на сторону. При этом после передачи файл резервной копии удаляется, несмотря на то, что для базы данных используется полная модель восстановления и создаются резервные копии журнала транзакций. Таким образом, восстановление на актуальный момент времени становится не возможным. Необходимо помнить простое правило: Если у базы данных используется Полная модель восстановления, то создание полной резервной копии без параметра COPY_ONLY, начнет новую цепочку резервных копий. Этот файл нельзя удалять, до того момента пока не будет создана новая полная резервная копия. Если вы хотите создать полную резервную копию и удалить её после передачи, то создавайте её с параметром COPY_ONLY. В QMB для этого следует установить признак «Только для копирования» см. рис.

При создании XML плана восстановления QMB автоматически выполняет проверку физического наличия файлов резервных копий, необходимых для восстановления. Это позволяет превентивно выявлять подобные ошибки нехватки нужного файла.

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

Если база данных была удалена или повреждена и ее можно восстановить любым из способов:

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

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

Процесс восстановления управляется мастером и немного отличается
в зависимости от того, восстанавливаете ли вы один образ базы данных, такой как
член Always on Availability Group (AG) или несколько образов в
экземпляр SQL.

Перед началом работы

Перед выполнением процедур этой главы убедитесь, что:

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

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

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

Операции восстановления обычно выполняются для восстановления
базу данных в допустимое состояние после события повреждения данных. Количество
время, необходимое для завершения традиционной операции восстановления, зависит от
объем задействованных данных.

Базы данных, использующие полное восстановление Microsoft SQL Server
Модель использует единую политику для захвата как базы данных, так и ее журналов.
Такую базу данных можно восстановить на любой момент времени, свернув ее
журналы вперед. Если вы восстанавливаете базу данных через консоль управления, указав Restore
При восстановлении база данных SQL Server будет восстановлена ​​и переведена в оперативный режим.
после применения логов.

Backup and DR поддерживает следующие распространенные варианты использования при восстановлении
Базы данных и экземпляры Microsoft SQL Server:

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

  • Использовать виртуальное приложение (Virtual Application Mount): Вы можете использовать
    Виртуальное монтирование приложения последней известной исправной версии поврежденного
    Экземпляр или база данных SQL Server как средство, позволяющее пользователям и приложениям
    возобновить работу как можно скорее. Затем базу данных можно перенести
    в фоновом режиме с помощью монтирования и миграции см. раздел монтирование и миграция SQL Server.

Примечание: Не используйте
Процедура восстановления для восстановления баз данных, являющихся членами Always On.
Группа доступности. Используйте возможность клонирования для параллельного клонирования.
на всех узлах группы доступности SQL. См. раздел Клонирование баз данных SQL Server.

Восстановление экземпляров и баз данных Microsoft SQL

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

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

Для запуска этой процедуры:

  • База данных Microsoft SQL Server должна быть подключена к сети. Если база данных не
    онлайн, операция восстановления завершится ошибкой во время проверки базы данных.

  • Дождитесь завершения запущенных заданий.

Чтобы восстановить базы данных SQL Server:

  1. Откройте Диспетчер приложений на странице Приложения .

  2. Щелкните правой кнопкой мыши базу данных Microsoft SQL Server для восстановления и выберите
    Доступ к из раскрывающегося списка. Страница доступа открывает список захваченных
    изображения в режиме линейного изменения временной шкалы. Типы изображений, которые поддерживают
    Операция восстановления включает Snapshot и OnVault, но только при использовании
    тот же прибор, который сделал снимок. При восстановлении с помощью другого
    требуется устройство, вместо этого используйте операцию клонирования.

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

  3. Выберите образ, затем выберите Восстановить из списка операций.
    Откроется страница восстановления.

  4. Выберите Традиционный для этой операции восстановления.

    Примечание. В большинстве случаев подключение и перенос является лучшим вариантом, так как
    приводит к почти нулевому времени простоя. Восстановления Mount and Migrate подробно описаны в
    Монтирование и миграция SQL Server.

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

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

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

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

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

  7. Нажмите Отправить .

    Откроется диалоговое окно с предупреждением. Прочтите его, а затем введите ПОТЕРЯ ДАННЫХ для подтверждения.
    Запустится задание восстановления. Вы можете убедиться, что операция восстановления
    успешно, просмотрев статус задания в системном мониторе.

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

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

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

  1. Перейти к Диспетчер приложений и выберите Приложения .
  2. Выберите и смонтируйте последний известный исправный образ группы консистентности.
    Не забудьте отменить выбор Создать новое виртуальное приложение .

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

     ВЫБЕРИТЕ имя, имя_физического_имени КАК текущее_местоположение_файла ИЗ sys.master_files

  4. Из экземпляра SQL используйте диспетчер конфигурации SQL Server
    или Services MMC, чтобы остановить исходный экземпляр SQL:

  5. С помощью проводника Windows или других средств перейдите к
    смонтированная резервная копия системных баз данных SQL.

  6. Скопируйте смонтированные файлы .mdf и .ldf для восстанавливаемой базы данных.

  7. С помощью проводника Windows или других средств перейдите к источнику
    База данных SQL Server:

  8. Вставьте файлы .mdf и .ldf в исходную базу данных SQL Server.

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

Восстановление в кластер SQL Server

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

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

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

Примечание: Для отказоустойчивого экземпляра SQL Server база данных всегда восстанавливается
к активному узлу. Устройство резервного копирования/восстановления монтирует образ резервной копии
к активному узлу и выполняет операцию восстановления на узле.
Для групп доступности SQL Server восстановление также выполняется на
активный узел.

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

Эта страница является одной из серии страниц, посвященных защите и восстановлению.
Базы данных Microsoft SQL Server с резервным копированием и аварийным восстановлением.
Дополнительную информацию можно получить по телефону:

  • Резервное копирование и аварийное восстановление для баз данных SQL Server
  • Требуемые роли SQL Server для пользователя Windows
  • Добавить узел базы данных SQL Server и обнаружить базы данных
  • Настройка планов резервного копирования для экземпляров и баз данных Microsoft SQL Server
  • Подключить базу данных SQL Server
  • Подключение баз данных к SQL Always On Availability Groups
  • Перенос базы данных SQL Server
  • Клонировать базы данных SQL Server
  • Восстановление резервных копий SQL Server

Полное руководство по резервному копированию и восстановлению SQL Server с помощью командной строки

Создание резервных копий базы данных SQL Server — один из наиболее важных аспектов обслуживания системы. Существуют различные инструменты для создания резервных копий, такие как SQL Server Management Studio, SqlBak и SQLBackupAndFTP. Однако выполнение резервного копирования через интерфейс командной строки может обеспечить еще большую гибкость и возможности настройки.

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

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

SQL для резервного копирования базы данных

Чтобы выполнить резервное копирование SQL Server с помощью T-SQL, вы можете использовать оператор BACKUP DATABASE . Этот оператор создает полную резервную копию указанной базы данных, которую можно использовать для восстановления базы данных до ее состояния на момент создания резервной копии.

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

 BACKUP DATABASE [имя_базы_данных]
НА ДИСК = 'C:\Backup\backup_file.bak'
С ИНИТ
  • [имя_базы_данных] — Имя базы данных для резервного копирования.
  • TO DISK = 'C:\Backup\backup_file.bak' — Путь и имя создаваемого файла резервной копии. Это может быть любой допустимый путь к файлу и имя файла.
  • WITH INIT — этот параметр перезаписывает любой существующий файл резервной копии с тем же именем, что и у создаваемого.

Вы можете изменить параметры в предложении WITH в соответствии со своими конкретными потребностями в резервном копировании. Например, вы можете включить сжатие, чтобы уменьшить размер файла резервной копии и отобразить информацию о ходе резервного копирования, используя параметры СЖАТИЕ и СТАТИСТИКА соответственно.

Обратите внимание, что для выполнения резервного копирования с помощью T-SQL пользователь должен иметь достаточные права для выполнения инструкции BACKUP DATABASE и доступа к указанному пути к файлу резервной копии.

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

Чтобы восстановить базу данных SQL Server из файла резервной копии, вы можете использовать оператор RESTORE DATABASE в T-SQL. Основной синтаксис для восстановления базы данных из файла резервной копии выглядит следующим образом:

 RESTORE DATABASE [имя_базы_данных]
С ДИСКА = 'C:\Backup\backup_file.bak'
С ВОССТАНОВЛЕНИЕМ
  • [database_name] — Имя восстанавливаемой базы данных.
  • С ДИСКА = 'C:\Backup\backup_file.bak' — Путь и имя файла резервной копии для восстановления.
  • WITH RECOVERY — этот параметр указывает, что базу данных следует оставить в восстановленном состоянии, чтобы сделать ее доступной для использования.

Обратите внимание, что для восстановления базы данных с помощью T-SQL пользователь должен иметь достаточные права для выполнения инструкции RESTORE DATABASE и доступа к указанному пути к файлу резервной копии.

Восстановление базы данных с другим именем

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

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

 ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ [имя_новой_базы_данных]
С ДИСКА = 'C:\Backup\backup_file. bak'
WITH MOVE '[original_logical_data_file_name]' TO '[new_physical_data_file_path]',
     MOVE '[original_logical_log_file_name]' TO '[new_physical_log_file_path]'
  • [new_database_name] — Новое имя восстанавливаемой базы данных.
  • С ДИСКА = 'C:\Backup\backup_file.bak' — Путь и имя файла резервной копии для восстановления.
  • С ПЕРЕМЕЩЕНИЕМ — этот параметр сопоставляет имена логических файлов в файле резервной копии с новыми именами физических файлов и путями для файлов базы данных.

При восстановлении базы данных с другим именем необходимо использовать параметр WITH MOVE , чтобы указать новые имена физических файлов и пути для файлов базы данных. Этот параметр сопоставляет имена логических файлов в файле резервной копии с новыми именами и путями физических файлов. MOVE  требуются два параметра: исходное логическое имя файла и новый физический путь к файлу.

Для определения логических имен файлов данных и файлов журнала в файле резервной копии можно использовать следующую инструкцию T-SQL:

 RESTORE FILELISTONLY FROM DISK = 'C:\Backup\backup_file.bak'

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

Например, чтобы восстановить базу данных с именем «AdventureWorks» как «AdventureWorksCopy» с файлом данных, перемещенным в «C:\Data\AdventureWorksCopy.mdf», а файл журнала — в «C:\Log\AdventureWorksCopy.ldf», вы должны использовать следующий оператор T-SQL:

 ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ AdventureWorksCopy
С ДИСКА = 'C:\Backup\AdventureWorks.bak'
С ПЕРЕМЕЩЕНИЕМ 'AdventureWorks_Data' В 'C:\Data\AdventureWorksCopy.mdf',
     ПЕРЕМЕСТИТЕ 'AdventureWorks_Log' В 'C:\Log\AdventureWorksCopy. ldf'

Командная строка резервного копирования SQL Server

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

В этой статье все подключения к базе данных выполняются с использованием проверки подлинности Windows. Если вы используете проверку подлинности SQL Server, вам потребуется указать параметры -U и -P при использовании sqlcmd. При использовании модуля PowerShell Backup-SqlDatabase для проверки подлинности SQL Server данные подключения передаются через параметр -SqlCredential. Обязательно обратите внимание, чтобы избежать ошибок при выполнении команд.

sqlcmd Резервное копирование базы данных на локальный диск

sqlcmd — это утилита командной строки, предоставляемая Microsoft для взаимодействия с SQL Server. Он позволяет выполнять операторы SQL, хранимые процедуры и файлы сценариев, а также выполнять различные административные задачи.

Чтобы выполнить резервное копирование SQL Server с помощью sqlcmd , можно использовать параметр -Q для указания выполняемой команды резервного копирования. Основной синтаксис для резервного копирования базы данных с использованием sqlcmd выглядит следующим образом:

 sqlcmd -S [имя_сервера] -Q "РЕЗЕРВНАЯ БАЗА ДАННЫХ [имя_базы_данных] НА ДИСК='C:\Backup\backup_file.bak' С INIT"
  • -S [имя_сервера] — имя экземпляра SQL Server для подключения.
  • -Q — указывает выполняемый запрос.
  • «BACKUP DATABASE [database_name] TO DISK='C:\Backup\backup_file. bak' WITH INIT» — Команда резервного копирования, которую нужно выполнить.

sqlcmd восстановление базы данных с локального диска

Чтобы восстановить базу данных SQL Server с помощью sqlcmd , можно использовать параметр -Q , чтобы указать команду восстановления, которая должна быть выполнена. Основной синтаксис для восстановления базы данных с помощью sqlcmd выглядит следующим образом:

 sqlcmd -S [server_name] -Q "ВОССТАНОВЛЕНИЕ DATABASE [database_name] FROM DISK='C:\Backup\backup_file.bak' WITH RECOVERY
    90 005
    -S [имя_сервера] — имя экземпляра SQL Server для подключения.
  • -Q — указывает выполняемый запрос.
  • RESTORE DATABASE [database_name] FROM DISK='C:\Backup\backup_file. bak' WITH RECOVERY — команда восстановления, которую необходимо выполнить.

PowerShell SQL Резервное копирование всех баз данных

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

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

Install-Module -Name SqlServer

После установки модуля вы можете использовать командлет Backup-SqlDatabase для выполнения резервного копирования. Командлет позволяет указать базу данных для резервного копирования, путь к файлу резервной копии и различные параметры резервного копирования.

Для резервного копирования всех баз данных на экземпляре SQL Server можно использовать следующую команду:

 Get-ChildItem "SQLSERVER:\SQL\[имя-сервера]\[имя-экземпляра]\базы данных" | Backup-SqlDatabase -BackupContainer "[backup-path]"

Замените [имя-сервера] , [имя-экземпляра] и [backup-path] соответствующими значениями для вашей среды. Командлет Get-ChildItem извлекает все базы данных в указанном экземпляре SQL Server и передает их командлету Backup-SqlDatabase для резервного копирования.

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

 Get-ChildItem "SQLSERVER:\SQL\MSI\DEFAULT\Databases" | Backup-SqlDatabase -BackupContainer "c:\Backups2\"

Эта команда выполняет резервное копирование всех баз данных на экземпляре SQL Server «MSI» в папку «c:\Backups2».

Дифференциальное резервное копирование PowerShell SQL Server

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

Чтобы выполнить разностное резервное копирование с помощью PowerShell, используйте командлет Backup-SqlDatabase с параметром -Incremental . Вот пример:

 Backup-SqlDatabase -ServerInstance "." -База данных "AdventureWorks" -BackupFile "C:\Backups\AdventureWorks_diff.bak" -Incremental

Эта команда создает дифференциальную резервную копию базы данных “AdventureWorks” и сохраняет ее в файл “C:\Backups\AdventureWorks_diff. bak”.

База данных восстановления SQL PowerShell

Помимо создания резервных копий, PowerShell также можно использовать для восстановления баз данных SQL Server. Модуль SQLServer предоставляет командлет Restore-SqlDatabase для восстановления баз данных из файлов резервных копий.

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

 Restore-SqlDatabase -ServerInstance [экземпляр-сервера] -Database [имя-базы-данных] -BackupFile [файл-резервной копии] -ReplaceDatabase
  • -ServerInstance [сервер-экземпляр] — имя экземпляра SQL Server для подключения.
  • -Database [имя-базы-данных] — Имя базы данных, которую необходимо восстановить.
  • -BackupFile [backup-file] — Путь и имя файла резервной копии для восстановления.
  • -ReplaceDatabase — этот параметр указывает, что существующая база данных должна быть заменена восстановленной базой данных.

Вот пример восстановления базы данных с помощью PowerShell:

 Restore-SqlDatabase-ServerInstance '.' -База данных «MyDatabase» -BackupFile «C:\Backup\MyDatabase.bak» -ReplaceDatabase

Эта команда восстанавливает базу данных «MyDatabase» из файла резервной копии, расположенного в «C:\Backup\MyDatabase.bak», на локальный сервер SQL. instance и заменяет существующую базу данных, если она существует.

PowerShell SQL Server Restore Differential Backup

Чтобы восстановить базу данных SQL Server из дифференциальной резервной копии с помощью PowerShell, сначала необходимо восстановить полную резервную копию с помощью -NoRecovery , затем восстановите разностную резервную копию.

Чтобы восстановить полную резервную копию, используйте командлет Restore-SqlDatabase с параметрами -NoRecovery и -ReplaceDatabase . Вот пример:

 Restore-SqlDatabase -ServerInstance '.' -База данных «AdventureWorks» -BackupFile «C:\Backups\AdventureWorks_full.bak» -NoRecovery -ReplaceDatabase

Эта команда восстанавливает полную резервную копию базы данных «AdventureWorks» из файла резервной копии «C:\Backups\AdventureWorks_full.bak» в локальный экземпляр SQL Server и заменяет существующую базу данных, если она существует.

После восстановления полной резервной копии можно восстановить дифференциальную резервную копию с помощью того же командлета Restore-SqlDatabase без параметра -NoRecovery . Вот пример:

 Restore-SqlDatabase -ServerInstance '.' -Database 'AdventureWorks' -BackupFile 'C:\Backups\AdventureWorks_diff.bak'

Эта команда восстанавливает разностную резервную копию базы данных “AdventureWorks” из файла резервной копии “C:\Backups\AdventureWorks_diff.bak” на локальный сервер SQL Server. пример.

Сценарии резервного копирования

Хотя однострочные команды могут быть полезны, сценарии резервного копирования предоставляют больше возможностей и могут автоматизировать процесс резервного копирования. Сценарии резервного копирования могут быть написаны на разных языках, таких как пакетная обработка, PowerShell и Bash, в зависимости от ваших потребностей и среды.

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

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

 

 @эхо выключено

установить DB_NAME=MyDatabaseName
установить BACKUP_DIR=C:\Backups
установить DAYS_TO_KEEP=0

echo Запуск резервного копирования базы данных %DB_NAME%...

sqlcmd -E -S . -Q "РЕЗЕРВНАЯ БАЗА ДАННЫХ %DB_NAME% НА ДИСК='%BACKUP_DIR%\%DB_NAME%_%date:/=-%_%time::=-%.bak' С INIT, СЖАТИЕ"

если %ERRORLEVEL% neq 0 (
    echo Сбой резервного копирования с кодом ошибки %ERRORLEVEL%.
    eventcreate /T ERROR /L APPLICATION /ID 100 /D "Сбой резервного копирования SQL Server с кодом ошибки %ERRORLEVEL%."
    перейти к концу
)

echo Удаление старых файлов резервных копий старше %DAYS_TO_KEEP% дней в каталоге %BACKUP_DIR% ...

forfiles /P "%BACKUP_DIR%" /M "%DB_NAME%*.bak" /D -%DAYS_TO_KEEP% /C 2>nul "cmd /c if @ISDIR==FALSE del @PATH"

echo Старые файлы резервных копий успешно удалены.

:конец
эхо Сценарий завершен.

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

Сценарий PowerShell для резервного копирования всех баз данных SQL

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

  • Получает список всех баз данных SQL Server
  • Подключает сетевой диск
  • Создает резервную копию каждой базы данных
  • Сжимает файл резервной копии
  • Копирует файл резервной копии на сетевой диск
  • Удаляет просроченные резервные копии
  • Размонтирует сетевой диск
  • Отправляет уведомление об ошибке, если произошла ошибка
 вызов-sqlcmd

# Установить переменные
$backupFolderPath = "C:\temp" # Путь к папке резервного копирования
$compressionLevel = "2" # Уровень сжатия архива (1-9)
$expirationDays = 7 # Количество дней, по истечении которых резервные копии будут удалены

# Установить учетные данные для сетевого диска
$networkDrive = "Z" # Временный сетевой диск
$networkPath = "\\сервер\резервная копия\папка"
$networkUser = "сетевой пользователь"
$networkPassword = "сетевой пароль"

$eventLogName = "Приложение"
$eventSource = "MSSQLSERVER"

Write-Host «Запуск сценария резервного копирования базы данных SQL Server»

# Получить список всех баз данных SQL Server
$databases = Get-ChildItem "SQLSERVER:\SQL\MSI\DEFAULT\Databases" | Где-Объект {$_. Name -ne "tempdb"}

Write-Host "Найдены базы данных $($databases.Count)"

# Создать резервную папку, если она не существует
если (!(Тест-Путь -Путь $backupFolderPath)) {
    New-Item -ItemType Directory -Path $backupFolderPath | Out-Null
    Write-Host "Создана папка резервного копирования: $backupFolderPath"
}

New-PSDrive -Name $networkDrive -PSProvider FileSystem -Root $networkPath -Credential (New-Object System.Management.Automation.PSCredential($networkUser,(ConvertTo-SecureString $networkPassword -AsPlainText -Force)))
# Подключить сетевой диск

# Резервное копирование баз данных
foreach (база данных $ в базе данных $) {
    Write-Host "Создание резервной копии для базы данных $($database.Name)"
    $backupFile = Join-Path $backupFolderPath "$($database.Name)_$(Get-Date -Format 'yyyyMMdd_HHmmss').bak"
    Backup-SqlDatabase -ServerInstance "." -База данных $database.Name -BackupFile $backupFile -Инициализировать

    если ($?) {
        Write-Host «Резервная копия базы данных $($database. Name) создана».
    } еще {
        $errorDetails = "Ошибка создания резервной копии базы данных $($database.Name). Подробности: " + $Error[0].Exception.Message
        Write-EventLog -LogName $eventLogName -Source $eventSource -EntryType Error -EventId 1 -Message $errorDetails
        продолжать
    }

    Write-Host "Создана резервная копия для базы данных $($database.Name)"

    # Сжать резервную копию
    $zipFile = "$backupFile.zip"
    Compress-Archive -Path $backupFile -CompressionLevel Optimal -DestinationPath $zipFile

    если ($?) {
        Write-Host «Резервная копия для базы данных $($database.Name) была заархивирована».
    } еще {
        $errorDetails = "Ошибка создания резервной копии базы данных $($database.Name). Подробности: " + $Error[0].Exception.Message
        Write-EventLog -LogName $eventLogName -Source $eventSource -EntryType Error -EventId 1 -Message $errorDetails
        продолжать
    }

    Write-Host "Сжатая резервная копия $($backupFile)"

    # # Скопировать файл на сетевой диск
    cp $zipFile "$($networkDrive):\$(Split-Path $zipFile -leaf)"

    если ($?) {
        Write-Host «Резервная копия базы данных $($database. Name) создана и успешно отправлена ​​в хранилище».
    } еще {
        $errorDetails = "Ошибка создания резервной копии базы данных $($database.Name). Подробности: " + $Error[0].Exception.Message
        Write-EventLog -LogName $eventLogName -Source $eventSource -EntryType Error -EventId 1 -Message $errorDetails
        продолжать
    }

    # Удалить просроченные резервные копии
    Get-ChildItem $backupFolderPath -Recurse | Where-Object {($_.LastWriteTime -lt (Get-Date).AddDays(-$expirationDays)) -and ($_.Extension -eq ".zip")} | Убрать предмет

    # Удалить просроченные резервные копии из хранилища резервных копий
    Get-ChildItem "$($networkDrive):\" -Recurse | Where-Object {($_.LastWriteTime -lt (Get-Date).AddDays(-$expirationDays)) -and ($_.Extension -eq ".zip")} | Убрать предмет

    Write-Host "Удаленные резервные копии с истекшим сроком действия"

    # Отправить уведомление об ошибке, если произошла ошибка
}

Write-Host «Сценарий резервного копирования базы данных SQL Server завершен»

# # Размонтировать сетевой диск
Remove-PSDrive-Name $networkDrive

Инструмент резервного копирования командной строки SQL Server

Вместо самостоятельного создания сложного сценария PowerShell или Bash можно использовать утилиту sqlbak-cli .

SqlBak-CLI — это простой инструмент командной строки для создания резервных копий базы данных и отправки их в хранилище. Эта утилита также может восстанавливать резервные копии, которые она создает. Он может отправлять резервные копии в сетевые папки, FTP, SFTP и Backblaze. Документацию и инструкции по загрузке можно найти по этой ссылке.

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

Резервное копирование всех баз данных на другой сервер через SSH с помощью SqlBak-CLI

Создайте файл с именем backup-job-settings.json с подробностями подключения для базы данных и сетевой папки.

 {
    "источник":
        {
            "тип": "mssql",
            "имя_источника":"имя-источника",
            "источник данных":".",
            «trust_server_certificate»: правда,
            «is_integrated_security»: ложь,
            "имя_пользователя":"sa",
            "пользовательский пароль":"*******",
            "базы данных": [ "mssql_custom" ]
        },
       "хранилища": [
          {
             "тип": "sftp",
             "server_name":"backup-storage. com",
             "user_name":"ftp-пользователь",
             "пользовательский пароль":"*************",
             "путь":"резервные копии"
          }
       ]
}

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

 sqlbak-cli run-backup --job-settings=backup-settings.json

Восстановите базу данных на другом сервере через SSH с помощью SqlBak-CLI

Чтобы восстановить backup создайте файл с именем restore-job-settings.json.

 {
    "тип": "восстановить",
    "цель": {
    "тип": "mssql",
    "источник данных":".",
    «trust_server_certificate»: правда,
    "имя_пользователя":"sa",
    "пользовательский пароль":"********",
    "базы данных": [
            {
                "имя_источника": "Вордпресс",
                "target_name": "Вордпресс"
            }
        ],
    },
    "хранилище": {
        "тип_назначения":"sftp",
        "server_name":"backup-storage. com",
        "user_name":"ftp-пользователь",
        "пользовательский пароль":"*************",
        "путь":"резервные копии"
    }
}

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

 sqlbak-cli run-restore --job-settings=restore-settings.json

Автоматизация резервного копирования с помощью SqlBak-CLI, PowerShell и пакетных сценариев

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

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

  1. Откройте планировщик заданий, введя «Планировщик заданий» в меню «Пуск» и щелкнув соответствующий результат.
  2. Нажмите «Создать простую задачу» на панели «Действия» в правой части окна планировщика заданий.
  3. Назовите задачу и нажмите «Далее».
  4. Выберите периодичность резервного копирования и нажмите «Далее». Например, если вы хотите создавать резервную копию базы данных каждый день в полночь, выберите «Ежедневно» и установите время на 00:00.
  5. Выберите «Запустить программу» в качестве действия для задачи и нажмите «Далее».
  6. Введите путь к вашему скрипту резервного копирования в поле «Программа/скрипт». Для SqlBak-CLI это может быть «sqlbak-cli.exe». Для PowerShell это может быть «powershell.exe». Для пакетной обработки это может быть «cmd.exe».
  7. Для SqlBak-CLI:
    В поле «Программа/скрипт» введите путь к файлу sqlbak-cli.exe. Например: C:\Program Files\SQLBak-CLI\sqlbak-cli.exe .
    В поле «Добавить аргументы (необязательно)» введите run-backup и путь к JSON-файлу задания резервного копирования: run-backup --job-settings=C:\backup\my-backup-job. json .
  8. Для PowerShell:
    В поле «Программа/скрипт» введите путь к файлу powershell.exe. Например: powershell.exe .
    В поле «Добавить аргументы (необязательно)» введите путь к файлу сценария PowerShell, например: -File C:\Users\UserName\Documents\backup.ps1 .
  9. Для пакета:
    В поле «Программа/скрипт» введите путь к файлу cmd.exe. Например: cmd.exe .
    В поле «Добавить аргументы (необязательно)» введите путь к вашему командному файлу, например: C:\Users\UserName\Documents\backup.bat .
  10. Нажмите «Далее», просмотрите сведения о задаче и нажмите «Готово».

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

Заключение

Резервное копирование базы данных — не единственная задача, которую должен выполнять администратор БД.