Резервное копирование баз данных [BS Docs 5]
Резервное копирование баз данных можно производить несколькими способами:
Для создания резервной копии базы данных необходимо выделить ее в дереве объектов SQL Server Management Studio2), в контекстном меню выбрать пункт «Задачи → Создать резервную копию…».
Рисунок 1В окне «Резервное копирование базы данных» (Рис. 1) на странице Общие в разделе «Источник» в поле «Тип резервной копии выбрать Полная; в разделе «Назначение» по кнопке «Добавить» указать файл резервной копии базы данных. Для проверки целостности копии базы данных на закладке Параметры в разделе «Надежность» установить флаг Проверить резервную копию после завершения.
Нажатием кнопки «OK» запустить создание резервной копии выбранной базы данных и дождаться сообщения «Резервное копирование базы данных «<имя_базы>» успешно завершено.
Настройка автоматического резервного копирования баз данных возможна разными способами. Здесь приведена схема работы скрипта, создающего резервные копии указанных баз данных в указанные папки.
Схема работы:
- Скрипт запускается непосредственно на SQL Server’e, имя инстанции SQL Server указывается в скрипте. Для выполнения SQL-кода указывается путь к соответствующей утилите. Создается резервная копия базы данных с указанием даты в имени файла. Файл сохраняется локально по указанному пути. Создаются лог-файлы резервного копирования для каждой базы с указанием имени базы в названии файла и общий лог-файл.
Файл резервной копии запаковываются архиватором. В скрипте необходимо указать используемый архиватор.
Созданный архив копируется на указанные сетевые источники хранения архивов при необходимости.
Старые архивы удаляются. В скрипте указывается утилита для удаления файлов.
Руководство по панели управления.
BackUp. LTD Beget.BackUp — это резервное копирование файлов/папок с файлами ваших проектов на отдельные сервера.
В Панели управления, в разделе BackUp вы можете сохранить копию файлов и баз данных ваших проектов, восстановить проект из бекапа и посмотреть детальный отчёт по сделанным бекапам.
Восстановление из автоматически созданного бекапа
В среднем раз в три дня (зависит от нагрузки системы) система создаёт автоматическую копию (бекап) файлов и баз данных. Бекапы хранятся на отдельных серверах. Список бекапов расположен в верхней части таблицы справа. Там же находятся три кнопки меняющие вид таблицы: файловый архив, базы данных, история заданий.
Восстановление файлов из бекапа
Чтобы восстановить файл(лы) или папку проекта, выберите из списка бекап нужный вам даты, отметьте галочкой файлы или папки для восстановления и нажмите «Восстановить из резервной копии»
После нажатия на кнопку вы увидите предупреждение.
Нажмите на кнопку Восстановить, чтобы подтвердить процедуру восстановления.
Выбранные вами данные будут перемещены на ваш аккаунт, на все файлы выставятся права 700. Время выполнения данной операции варьируется в зависимости от размера данных, по завершении процедуры вам на почту придёт письмо. В нём будет статус восстановления и список восстановленных файлов.
Восстановление базы данных
Процесс восстановления базы данных схож с процессом восстановления файлов:
- Активируйте режим отображения баз данных в таблице;
- Выберите сохраненную копию базы данных;
- Отметьте галочкой базу данных для восстановления;
- Запустите процесс восстановления кнопкой .
После нажатия кнопки вам будет выведено предупреждение:
Для подтверждения восстановления базы данных нажмите кнопку Восстановить. После завершения восстановления вам на почту придёт письмо со статусом процедуры и списком восстановленных баз.
Узнать статус процедуры восстановления также можно в таблице, переключив ей в режим отображения истории заданий.
История заданий
В таблице истории заданий отображаются статусы и типы операций, а также даты и время начала и завершения заданий. Нажав на статус мышью, вы получите детальный отчёт о выполненной операции.
Выгрузка резервной копии и восстановление из неё
Автоматическое сохранение происходит каждые 3 дня, однако вы в любой момент можете сделать выгрузку резервной копии по требованию. Для этого установите галочку напротив файлов или папок, копию которых нужно сохранить и нажмите на кнопку Выгрузить резервную копию .
После нажатия на кнопку появится информационное окно, в котором вам будут предложены несколько вариантов выгрузки бекапа.
Вариант 1: скачать бекап по прямой ссылкеВ этом случае будет создан архив, который вы сможете скачать к себе на локальную машину. Ссылка на скачивания будет в письме, которое вы получите после завершения операции. Также ссылка на архив будет доступна в
Обратите внимание!
Ссылка будет действовать 48 часов с момента окончания архивации.
Вариант 2: сохранить бекап в корне аккаунтаВыбрав этот вариант, архив с бекапом будет сохранён в корне вашего аккаунту. Имя архива будут содержать название папки, количество файлов в ней, дату создания архива. Расширение архива — gz.
Обратите внимание!
Размер резервной копии будет учтен в вашей дисковой квоте.
Автоматическое или ручное создание копий — удобный, бесплатный и надежный механизм, гарантирующий сохранность ваших данных. Однако, когда нужно создать вечную копию проекта, с большим количеством файлов, занимающих много дискового пространства — используется backup по требованию.
BackUp по требованию
В отличие от автоматического копирования backup по требованию создаёт резервную копию, которая хранится без ограничения по времени.
Обратите внимание!
Одна копия всегда бесплатно, каждая последующая — 2,00 руб/cутки.
Чтобы создать копию, достаточно написать комментарий и нажать на кнопку Создать вечный backup. После чего бекап появится в списке резервных копий.
Для восстановления из бекапа, нажмите на сохраненную копию. Вас перебросит в раздел «Автоматическое копирование»
Резервное копирование — это удобный и надежный инструменты обеспечения безопастности и сохранности ваших проектов.
Бэкап сайта: что такое и как грамотно его сделать
- Что такое Backup
- Зачем он нужен?
- Как его сделать?
Что это такое бэкап сайта?
Суть бэкапа сайта сводится к копированию баз данных, файлов сайта, почты, FTP-аккаунтов и множества других параметров хостинга. Проще говоря, мы сохраняем весь сайт и его настройки в отдельном месте и, при необходимости, можем вернуть сайт к той версии, которую сохранили. При этом может осуществляться копирование данных на текущий и бэкапный (дополнительный) сервер, располагающийся отдельно от серверов провайдера либо в другом дата-центре. Оно производится на случай, если что-то случится с сервером на котором хранится сайт.
Для чего нужно резервное копирование сайта?
Вы можете восстановить выполненный хостинг-провайдером бэкап, используя панель управления хостинг-аккаунтом, или обратившись к провайдеру, а затем начать работать над повышением уровня безопасности вашего сайта, а не заниматься восстановлением контента своего сайта по частям.
Однако может возникнуть и другая более сложная проблема – в результате какого-либо стихийного бедствия работоспособность сервера нарушается, и он, как и все сайты и бэкапы, содержащиеся на нем, также перестает работать. Для таких форс-мажорных случаев и предусмотрен сервис двойного резервного копирования.
У хостинг-провайдера имеется возможность оперативно восстановить работу своих сервисов и выполнить восстановление бэкапов данных пользователей, взяв их из другого бэкапного сервера, который расположен в другом дата-центре, и на который не повлияли форс-мажорные обстоятельства, нарушившие работу сайтов.
Поэтому перед приобретением хостинга обязательно поинтересуйтесь у провайдера предлагает ли он своим заказчикам сервис резервного копирования ваших данных и насколько регулярно он это выполняет и сколько времени хранит копии. Этот фактор существенно снизит риск потери данных.
Зачем сохранять к себе на компьютер?
Мы рекомендуем еженедельно сохранять к себе на компьютер резервную копию сайта. Это нужно на тот случай, если сайт был взломан месяц назад, а провайдер хранит бэкапы только 2 недели. В таком случае все копии сайта на сервере провайдера будут заражены.
Как сделать бэкап сайта?
Основная задача будет состоять в том, чтобы сохранить к себе на компьютер файлы сайта и базу данных, которые находятся на сервере хостера. Есть несколько вариантов того, как делать бэкап сайта. И сейчас мы их рассмотрим подробно.
С помощью хостинг-аккаунта
Заходите в панель управления хостингом и находите там раздел похожий на «Резервные копии», «Backup» или что-то подобное. Далее два пути:
- провайдер создаст копию (в одном архиве) и даст Вам ссылку чтобы скачать.
- провайдер сделает копию, и ее нужно будет скачать с сервера (на котором расположен Ваш сайт) с помощью FTP-клиента (обычно файл с копией находится в папке backup или подобной) или скачать через менеджер файлов в панели управления хостингом.
С помощью FTP-клиента и phpMyadmin
Начинаем с того, что устанавливаем и настраиваем FTP-клиент (это целесообразно делать в случае, если у хостинг-провайдера не реализована загрузка файлов через собственный файл-менеджер). После этого с его помощью скачиваем себе на компьютер абсолютно все файлы сайта, хранящиеся на сервере хостинг-провайдера. После этого с его помощью, скачиваем себе на компьютер абсолютно все файлы сайта, хранящиеся на сервере хостинг-провайдера.
Затем нужно скопировать базу данных на свой компьютер (еще называют создать дамп базы данных).
Как вернуть сайт к сохраненной версии?
Если в будущем вам понадобится вернуть сайт к той версии, которую вы сохранили на компьютер, то удалите полностью все файлы на сервере (не трогайте файлы настроек, удаляйте только из той папки, где хранятся файлы сайта, например public_html, www и т.д.). Сайт полностью перестанет работать (это не надолго). После этого очистите все таблицы в базе данных сайта (через phpMyadmin) и импортируйте в пустую БД ту базу данных, которая сохранена на Вашем компьютере. После этого загружайте файлы сайта на сервер и сайт должен заработать. Причем это будет та версия сайта, которую вы заранее сохраняли на свой компьютер.
На сколько часто нужно делать резервные копии сайта?
Желательно делать это несколько раз в месяц (речь о резервных копиях, которые вы делаете самостоятельно и загружаете к себе на компьютер). Обычно резервные копии создаются автоматически самим хостером и хранятся там около 2 недель. Мы рекомендуем загружать их себе на диск (или облачное хранилище типа Дропбокс) примерно 1-2 раза в месяц. Для большинства сайтов это будет хорошим соотношением усилий и эффективности.
Сколько бэкапов нужно постоянно хранить?
Это зависит от того, насколько часто обновляется ваш сайт. Оптимальным для большинства сайтов можно назвать количество бэкапов за год, если делать их 1-2 раза в месяц, то получается 12-25 копий.
Зачем делать бэкап сайта? — польза резервного копирования сайта
Бэкап — это ручное или автоматическое дублирование информации с целью последующего восстановление данных в случае их повреждения или полного уничтожения. В рамках услуг хостинга можно обозначить два вида бэкапов. Первый — это бэкап файлов сайта, а второй — это бэкап базы данных, в связке с которой работает сайт. Давайте рассмотрим случаи, когда рекомендуется создавать резервную копию файлов сайта и базы данных.
Плановое резервное копирование
В качестве создания контрольной точки для восстановления информации. Бывают случаи, когда самая надежная система дает сбой. По этой причине необходимо всегда иметь рабочую версию сайта. Тем самым, при возникновении форс-мажорной ситуации, вы всегда будете иметь под рукой спасительный бэкап, который поможет восстановить работоспособную версию сайта.
Перед внесением изменений
Например при обновлении ядра CMS, модулей, плагинов, компонентов. Если вы решили внести какие-либо изменения на сайте, то в этом случае также рекомендуется сохранить резервную копию файлов и базы данных. Нужно это для того, чтобы в случае появления ошибок, которые могут возникнуть в ходе обновления сайта, можно было оперативно восстановить рабочую версию сайта.
При доработках на сайте
В случае если на сайте проводятся плановые работы, также настоятельно рекомендуется сохранять резервную копию файлов или таблиц базы данных, на которых проводятся такие работы. Например, вы решили отредактировать системный файл сайта, добавив туда новый функционал. В случае, если вы совершите ошибку при условии, что резервная копия файла была заранее сохранена, вы сможете оперативно выполнить восстановление рабочей версии файла. Также вам стоит сделать бэкап сайта, если сайт дорабатывается сторонними специалистами.
Для защиты сайта
Если ваш сайт подвергся хакерской атаке, то при малейшем подозрении на взлом, необходимо сохранить резервную копию сайта и базы данных. Это необходимо потому, что вредоносный код в дальнейшем может вызвать частичный отказ в работе функционала сайта, а в некоторых случаях привести к полой потере данных. Во всех перечисленных случаях при наличии бэкапа сайта и базы данных можно избежать потери информации тем самым избавив вас от лишних трат времени и средств на восстановление работоспособности сайта.
Бекап на хостинге SpaceWeb
Как сделать бэкап сайта? На хостинге SpaceWeb резервные копии файлов и баз данных MySQL создаются автоматически каждый день.
В панели управлени хостингом в разделе «Бэкапы» вы можете просмотреть все имеющиеся резервные копии за последние 7 дней, и, при необходимости, восстановить данные из них, либо выложить архив с резервной копией на аккаунт. Примечание: рекомендуем регулярно использовать функцию «выложить архив с резервной копией на аккаунт». Таким образом у вас будут более старые резервные копии, а не только за последние 7 дней.
Восстановить сайт из бэкапа, автоматически созданного на хостинге, можно за один клик — достаточно выбрать дату и необходимые папки или базы данных.
Резервное копирование MySQL. Бэкап MySQL. Сделать бэкап MySQL
Резервное копирование и восстановление баз MySQL
В данном документе подробно рассматриваются принципы и процедуры, которые необходимо соблюдать для реализации стратегии резервного копирования MySQL на уровне предприятия при использовании агента Bacula Enterprise Edition для MySQL.
Данное руководство пользователя содержит описание различных методов и стратегий, чтобы проводить резервное копирование баз MySQLи их восстановление с помощью агента версии Enterprise. Эти методы также позволяют адаптировать и настраивать ПО с целью улучшения производительности, эффективности, скорости и масштабируемости различных подходов к резервному копированию баз MySQL и соответствующих данных.
Автоматическое резервное копирование MySQL разработано с целью упростить и ускорить процедуру резервного копирования баз MySQL, а также восстановление MySQL. Программное обеспечение для бэкапа базы данных MySQL и ее восстановления создано таким образом, что администратору не требуется ни знать, как работают встроенные инструменты резервного копирования MySQL, ни уметь создавать сложные скрипты. Автоматический бэкап MySQL с помощью Bacula автоматически создаст резервную копию важной информации, например конфигурации или определений пользователя. Бэкап базы данных MySQL также поддерживает два метода: резервное копирование с помощью дампа и бинарных логов.
Резервное копирование MySQL доступно для платформ Linux 32 и 64 бита (платформы Debian, Ubuntu, CentOS и др.), и поддерживает MySQL 4.0.x, 4.1.x, 5.0.x, 5.5.x, 5.6.x.
Как сделать бэкап MySQL: дамп или бинарный лог?
Таблица, приведенная ниже, поможет вам выбрать один из методов резервного копирования баз MySQL. Для того чтобы выбрать, как сделать бэкап базы данных MySQL, необходимо решить, хотите ли вы иметь возможность восстанавливать MySQL до определенной контрольной точки, или фильтровать объекты во время создания резервной копии или восстановления MySQL. Также можно комбинировать оба метода резервного копирования MySQL для одного сервера.
| Возможности автоматического бэкапа MySQL | Дамп файл | Бинарный лог |
| Возможность восстановления единичного объекта MySQL (таблица, схема…) | Да[1] | Нет |
| Скорость резервного копирования MySQL | Медленно | Быстро |
| Скорость восстановления MySQL | Очень медленно | Быстро |
| Размер бэкапа базы MySQL | Маленький | Большой |
| Возможность восстановления MySQL до контрольной точки | Да | Да |
| Поддержка инкрементального/дифференциального бэкапа MySQL | Да | Да |
| Онлайн бэкап MySQL | Да | Да |
| Согласованность | Да | Да |
| Восстановление MySQL до предыдущей основной версии | Да[2] | Нет |
| Возможность восстановить MySQL до новой основной версии | Да | Нет |
[1] Чтобы восстановить единичный объект MySQL, необходимо отредактировать дамп файл.
[2] Чтобы восстановить базу MySQL до предыдущей версии, Вам, возможно, потребуется отредактировать SQL файл, если вы используете функции, недоступные в предыдущей версии. Как правило, восстановление MySQL до предыдущей версии не поддерживается и не гарантируется.
Рисунок 1: Связь между бэкапом и бинарными логами
Автоматический бэкап MySQL с внутренним агентом
Автоматический бэкап базы данных MySQL в режиме дампа
На протяжении всего срока существования БД MySQL создает логи, которые можно использовать для репликации и/или защиты БД с помощью технологии P.I.T.R (восстановление MySQL до заданной контрольной точки). По умолчанию агент MySQL создает дамп каждой БД отдельно. Это значит, что, если вам нужно восстановить весь сервер, все БД будут согласованы по-отдельности, но их резервные копии не не будут создаваться в одно и тоже время. Значит базы данных MySQL не будут согласованы глобально. Чтобы решить данную проблему, агент для резервного копирования MySQL также будет сохранять лог файлы, создаваемые во время резервного копирования. Эти лог файлы можно будет считать впоследствии, чтобы гарантировать согласованность баз данных на определенный момент времени.
На рисунке 1, показан процесс создания бэкапов баз данных MySQL БД1, БД2 и БД3 (процесс занимает несколько часов). Во время данного процесса генерируются 3 лог файла. Эти файлы включаются в полный бэкап MySQL. Следующий инкрементальный или дифференциальный бэкап MySQL сохранит только бинарные логи, созданные после полного бэкапа. Чтобы гарантировать, что только одна копия каждого лог файла включена в бэкап, необходимо активировать функцию Accurate для выполнения задачи.
В примере выше, первый инкрементальный бэкап, созданный после полного бэкапа, будет включать логи 5 и 6, второй инкрементальный бэкап будет включать логи 7 и 8. Дифференциальный бэкап включал бы лог файлы 5, 6, 7 и 8. При использовании функции all_databases будут создаваться дампы всех БД одновременно. При этом лог файлы , созданные по завершении полного бэкапа, не будут включаться в него, а логи, сгенерированные до завершения задачи, будут включены в полный бэкап. В примере на рисунке 2 показано, что полный бэкап сгенерирует единый дамп файл «all-databases.sql», который будет включать лог файлы 2 и 3. Первый последующий инкрементальный бэкап будет включать логи 4, 5 и 6.
Рисунок 2: Связь между функцией all_databases и бинарными логами
Как сделать бэкап базы данных MySQL в режиме бинарных логов
В режиме бинарных логов инструмент MySQL использует программу Percona XtraBackup, которая представляет собой утилиту для создания горячего бэкапа серверов MySQL, которая не блокирует БД во время резервного копирования. Технология Percona использует методы, гарантирующие согласованность всего бэкапа MySQL.
Утилита бэкапа MySQL может создавать резервные копии данных из хранилищ InnoDB, XtraDB, и MyISAM на немодифицированных серверах MySQL 5.0, 5.1 и 5.5, также как это делает утилита Percona Server с XtraDB. Более подробную информацию об утилите Percona вы найдете на сайте:
http://www.percona.com/doc/percona-xtrabackup.
Оценка информации при бэкапе таблицы MySQL
Команда estimate позволяет отобразить всю информацию, найденную агентом MySQL. В случае режима дампа, наше ПО не может оценить размер дамп файла для БД. Вместо этого оно отобразит размер БД.
Информация о резервном копировании MySQL в режиме дампа
Агент MySQL сгенерирует следующие файлы в каталоге Bacula для сервера, имеющего единую БД “test”.
| Файл | Тип | Пояснение |
| global-grants.sql | глобальный | Список пользователей, их пароли и специальные функции |
| settings.txt | глобальный | Текущие переменные для mysql сервера |
| my.cnf | глобальный | Конфигурация MySQL |
| createdb.sql | БД | Скрипт создания БД |
| schema.sql | БД | Скрипт создания схемы БД |
| data.sql | БД | Данные БД в формате дампа |
| grants.sql | БД | Список всех пользователей, связанных с БД |
Таблица 2. Содержание бэкапа MySQL в режиме дампа
Восстановление MySQL
Bacula позволяет восстановить бэкап MySQL в нескольких режимах восстановления:
- Восстановление MySQL из дамп файла или бинарных логов
- Восстановление пользователей и ролей
- Восстановление единой БД MySQL
- Восстановление MySQL до контрольной точки
Чтобы восстановить бэкап MySQL в режиме бинарных логов, агент использует утилиту percona.
Рисунок 3: Содержимое сервера во время восстановления MySQL
Рисунок 4: Содержимое БД во время восстановления MySQL
Как сделать бэкап базы данных MySQL без использования плагина бесплатно
Создание дампа базы данных MySQL
Данный способ полностью бесплатен, поскольку позволяет делать бэкап MySQL с помощью open source версии Bacula Community и без дополнительных плагинов. Для резервного копирования небольших баз данных MySQL можно использовать простые bash-скрипты для резервного копирования баз данных. Для случая с резервным копированием баз MySQL можно сделать скрипт бэкапа MySQL, который будет запускаться на клиенте и делать dump базы данных MySQL.
#!/bin/bash
mysqldump -uuser -ppassword —all-databases | gzip > /opt/mysql_backup/backup.`date +%F`.sql.gz
find /home/bacula-backup/ -type f -mtime +3 -exec rm -f {} \;
Этот скрипт бэкапа MySQL сохранит дамп всех БД MySQL в директорию /opt/mysql_backup/ из которой мы и будем делать резервные копии дампов базы данных, при помощи директивы Client Run Before Job.
Пример задачи на бэкап базы MySQL:
Job {
Name = «BackupSmallMysqlServer»
Type = Backup
Level = Incremental
Client = mysqlserver1
FileSet = «mysqlserver»
Schedule = «WeeklyCycle»
Storage = SD1
Messages = Standard
Pool = Mysql
ClientRunBeforeJob = «/opt/sbin/mysql.sh»
SpoolAttributes = yes
Priority = 10
Write Bootstrap = «/var/lib/bacula/%c.bsr»
}
FileSet {
Name = «mysqlserver»
Include {
Options {
signature = MD5
compression = GZIP
}
File = /opt/mysql_backup/
}
}
Этот способ применим для бэкапа ненагруженных баз данных MySQL, например баз данных небольших сайтов, для которых блокировка таблиц во время дампа не критична
Как сделать бэкап нагруженных баз данных MySQL?
Если база данных MySQL сильно нагружена, то не рекомендуется на ней делать дамп, так как таблицы на время дампа блокируются. Самое правильно решение в этом случае — сделать реплику базы данных Master-Slave Replication.
Для нагруженных систем реплика требуется, чтобы в случае поломки базы данный Master, можно было переключить нагрузку на Slave и сделать его новым Master.
Для нагруженных систем резервное копирование MySQL необходимо делать именно для Slave базы данных.
Как восстановить данные из резервной копии (бэкапа)? — Вопросы и ответы — Джино
Чтобы восстановить бэкап файлов, войдите в раздел «Хостинг / Управление / Резервные копии» контрольной панели своего аккаунта, выберите дату, резервную копию от которой вам нужно восстановить, и файл или папку для восстановления. Запрошенные данные будут скопированы в директорию backups/дата на вашем аккаунте. Это может занять некоторое время, поэтому нужно подождать, пока объем файлов не перестанет увеличиваться или пока не пропадет желтое предупреждение на странице «Хостинг / Управление / Резервные копии». Затем вы сможете переместить их в нужное место при помощи файлового менеджера контрольной панели или FTP-доступа.
Вы можете восстановить и резервные копии ваших баз данных. Они также выкладываются в папку backups/дата в виде файла с SQL-инструкциями. Далее нужно скачать полученный файл .sql себе на компьютер и зайти в интерфейс phpMyAdmin («Хостинг / Управление / Управление MySQL»). В нем в левой колонке выберите базу данных, при необходимости удалите существующие таблицы и перейдите на вкладку «Импорт». Выбрав скачанный ранее дамп, нажмите кнопку «OK», и база будет восстановлена.
Если дамп БД слишком большой, то вы можете восстановить его, не скачивая на компьютер. Для этого подключите услугу «Поддержка SSH» и воспользуйтесь утилитой mysql:
mysql имя_базы -u имя_пользователя --password="пароль" < ~/backups/дата/имя_дампа.sql
Кроме файлов и баз данных, в том же разделе контрольной панели доступно и восстановление почты: просто выберите нужный почтовый ящик, и все удаленные из него с момента бэкапа письма будут загружены обратно (существующие письма при этом не удаляются — просто добавляются отсутствующие).
Обратите внимание, что для функционирования резервного копирования почты при работе по протоколу POP3 необходимо настроить почтовый клиент так, чтобы он оставлял копии писем на сервере. А лучше — работать с почтой по протоколу IMAP.
Смотрите также: Как часто производится резервное копирование?
Резервное копирование и восстановление баз данных Microsoft SQL Server
Для защиты виртуализованных серверов Microsoft SQL Server вы можете сконфигурировать задание резервного копирования, которое будет не только создавать резервные копии на уровне образа, но и копировать журналы транзакций. Резервные копии на уровне образа будут играть роль точек восстановления. Копии журналов транзакций будут содержать данные обо всех транзакциях, которые были выполнены с момента последнего резервного копирования. В случае аварии вы сможете восстановить виртуальную машину, на которой работает Microsoft SQL Server, на нужную точку восстановления, а затем применить журнал транзакций, чтобы вернуть базу данных в нужное состояние.
Для создания задания такого типа необходимо создать обычное задание резервного копирования и указать в нем настройки для копирования журналов транзакций. В настройках указывается:
- как часто необходимо копировать журналы транзакций;
- каким образом журналы транзакций должны копироваться на целевое устройство хранения;
- как долго необходимо хранить журналы транзакций.
При включении режима копирования журналов транзакций Veeam Backup & Replication создает 2 задания, связанных друг с другом:
- обычное задание резервного копирования;
- вспомогательное задание, которое копирует журналы транзакций баз данных Microsoft SQL Server.
Обычное задание резервного копирования запускается по расписанию. Оно создает резервную копию на уровне образа и сохраняет резервную копию в репозитории. После успешного создания резервной копии Veeam Backup & Replication обрезает журналы транзакций на виртуализованном сервере Microsoft SQL Server.
Вспомогательное задание работает в непрерывном режиме. Задание копирует журналы транзакций, которые накапливаются между точками восстановления виртуальной машины, с заданной периодичностью — например, раз в 15 минут. В результате в репозитории сохраняются точки восстановления и набор журналов транзакций, которые «покрывают» интервалы между этими точками восстановления.
Журналы транзакций копируются в репозиторий и сохраняются в файлах формата VLB рядом с файлами резервных копий. Для копирования журналов транзакций Veeam Backup & Replication использует серверы доставки (shipping servers) — машины под управлением Microsoft Windows, добавленные в инфраструктуру резервного копирования. Вы можете самостоятельно указать, какие серверы доставки вы хотите использовать или позволить Veeam Backup & Replication самостоятельно выбрать нужные серверы для копирования журналов транзакций.
Для восстановления баз данных Veeam Backup & Replication предлагает отдельный инструмент — Veeam Explorer for Microsoft SQL. Veeam Explorer for Microsoft SQL полностью интегрирован с Veeam Backup & Replication. Инструмент устанавливается автоматически при развертывании Veeam Backup & Replication.
Veeam Explorer for Microsoft SQL предлагает ряд сценариев восстановления:
- восстановление Microsoft SQL Server на определенную точку или определенную транзакцию.
- восстановление Microsoft SQL Server на определенную точку или определенную транзакцию и экспорт в нужное местоположение.
В этом разделе
Условия выполнения операции
Убедитесь, что для баз данных на Microsoft SQL Server используется модель полного восстановления (Full) или модель восстановления с неполным протоколированием (Bulk-logged). Если для базы данных используется простая модель восстановления (Simple), Veeam Backup & Replication не сможет обнаружить базы данных и обработать журналы транзакций.
Основные действия
Шаг 1. Создайте задание резервного копирования для виртуализованного сервера Microsoft SQL Server
- Сконфигурируйте задание резервного копирования для виртуальной машины, на которой установлен Microsoft SQL Server.
- На шаге мастера Guest Processing установите флаг Enable application-aware processing.
В разделе VM Guest OS credentials укажите данные учетной записи пользователя гостевой ОС виртуальной машины. Учетная запись должна иметь права sysadmin на Microsoft SQL Server. В противном случае Veeam Explorer для Microsoft SQL Server не сможет автоматически обнаружить базы данных Microsoft SQL Server в созданных резервных копиях.
- Нажмите Applications.
- Выберите в списке нужную виртуальную машину и нажмите Edit.
- Убедитесь, что на вкладке General в разделе Transaction logs выбрана опция Process transaction logs with this job.
- Перейдите на вкладку SQL.
- Выберите опцию Backup logs periodically.
- В поле Backup logs every <N> minutes укажите, как часто вы хотите копировать журналы транзакций с Microsoft SQL Server в репозиторий. По умолчанию, Veeam Backup & Replication запускает новый цикл копирования каждые 15 минут.
- В секции Retain log backups укажите, как долго вы хотите хранить журналы транзакций.
- Выберите опцию Until the corresponding image-level backup is deleted, если вы хотите хранить журналы до тех пор, пока предшествующая точка восстановления не будет удалена из цепочки резервных копий.
- Выберите опцию Keep only last … days, если вы хотите хранить журналы транзакций определенное количество дней. Укажите, какое количество дней вы хотите хранить журналы транзакций.
- В поле Log shipping servers оставьте выбранной опцию Automatic selection. Veeam Backup & Replication автоматически определит наименее загруженную машину под управлением Microsoft Windows в инфраструктуре резервного копирования и будет использовать ее для копирования журналов транзакций.
- На шаге Schedule установите флаг Run the job automatically. Если вы не установите эту опцию, задание резервного копирования не сможет автоматически копировать журналы транзакций в репозиторий.
- Сохраните настройки задания и запустите его. Veeam Backup & Replication создаст полную резервную копию виртуальной машины, на которой установлен Microsoft SQL Server.
- При включении режима копирования журналов транзакций создается 2 задания резервного копирования – основное и вспомогательное. Чтобы увидеть созданные задания, откройте представление Home и щелкните по узлу Last 24 hours в панели инструментов.
- Выполните какую-либо транзакцию в базе данных на виртуализованном сервере Microsoft SQL Server. Например, если вы используете тестовую базу данных, вы можете вручную запустить простой сценарий добавления записи или удаления записи в/из базы данных.
- Убедитесь, что интервал времени, который вы указали в поле Backup logs every <N> minutes, истек. По прошествии этого времени Veeam Backup & Replication запустит новый цикл копирования журналов транзакций.
Журналы транзакций будут скопированы и сохранены в файле формата VLB рядом с цепочкой резервных копий в репозитории.
Шаг 2. Восстановите базу данных на определенную транзакцию
- Откройте представление Backup & Replication.
- В иерархии объектов щелкните по узлу Backups.
- В рабочей области разверните задание резервного копирования, щелкните правой кнопкой мыши по виртуальной машине и выберите Restore application items > Microsoft SQL Server databases.
- Пройдите по шагам мастера Microsoft SQL Server Database Restore: выберите нужную точку восстановления и укажите причину восстановления базы данных. На последнем шаге мастера нажмите Finish.
Veeam Backup & Replication автоматически обнаружит базу данных в резервной копии и подсоединит ее к вспомогательному серверу Microsoft SQL Server. По умолчанию в роли вспомогательного сервера Microsoft SQL Server используется сервер, на котором развернута база даных Veeam Backup & Replication. Затем Veeam Backup & Replication запустит Veeam Explorer для Microsoft SQL и откроет в нем обнаруженную базу данных.
- Найдите нужную базу данных в панели слева, щелкните по ней и выберите Restore point-in-time state to <Microsoft SQL Server\Instance Name>.
- Veeam Backup & Replication запустит мастер восстановления баз данных. На шаге Specify restore point выберите Restore to a specific point in time. Чтобы выбрать состояние базы данных, перетащите бегунок в нужное место.
- Установите флаг Perform restore to the specific transaction и нажмите Next.
- На шаге Fine-tune the restore point выберите нужную транзакцию и нажмите Restore.
- Veeam Backup & Replication восстановит базу данных на выбранную транзакцию. После завершения процесса восстановления Veeam Explorer для Microsoft SQL Server покажет всплывающее сообщение с результатами операции восстановления.
Заключительные действия
Проверьте базу данных на виртуализованном сервере Microsoft SQL Server и убедитесь, что она восстановлена в требуемое состояние.
BACKUP (Transact-SQL) — SQL Server
Резервное копирование базы данных SQL.
Щелкните одну из следующих вкладок, чтобы просмотреть синтаксис, аргументы, примечания, разрешения и примеры для конкретной версии SQL, с которой вы работаете.
В следующей строке выберите название продукта, которое вас интересует, и отобразится только информация о нем.
SQL Server
Создает резервную копию всей базы данных SQL Server для создания резервной копии базы данных или одного или нескольких файлов или файловых групп базы данных для создания резервной копии файлов (BACKUP DATABASE).Кроме того, в рамках модели полного восстановления или модели восстановления с неполным протоколированием выполняется резервное копирование журнала транзакций базы данных для создания резервной копии журнала (BACKUP LOG).
Синтаксис
- Резервное копирование всей базы данных
РЕЗЕРВНАЯ БАЗА ДАННЫХ {имя_базы_данных | @database_name_var}
TO [, ... n]
[<Предложение MIRROR TO>] [next-mirror-to]
[С {ДИФФЕРЕНЦИАЛЬНЫМ
| [, ... n]}]
[;]
- Резервное копирование определенных файлов или файловых групп
РЕЗЕРВНАЯ БАЗА ДАННЫХ {имя_базы_данных | @database_name_var}
[,...n]
TO [, ... n]
[<Предложение MIRROR TO>] [next-mirror-to]
[С {ДИФФЕРЕНЦИАЛЬНЫМ | [, ... n]}]
[;]
--Создание частичной резервной копии
РЕЗЕРВНАЯ БАЗА ДАННЫХ {имя_базы_данных | @database_name_var}
READ_WRITE_FILEGROUPS [, [, ... n]]
TO [, ... n]
[<Предложение MIRROR TO>] [next-mirror-to]
[С {ДИФФЕРЕНЦИАЛЬНЫМ | [, ... n]}]
[;]
--Резервное копирование журнала транзакций (модели восстановления с полным и неполным протоколированием)
РЕЗЕРВНЫЙ ЖУРНАЛ
{имя_базы_данных | @database_name_var}
TO [,...n]
[<Предложение MIRROR TO>] [next-mirror-to]
[С { | \ <специфика-параметры-журнала>} [, ... n]]
[;]
<резервное_устройство> :: =
{
{логическое_имя_устройства | @logical_device_name_var}
| {ДИСК
| ЛЕНТА
| URL} =
{'имя_ физического_устройства' | @physical_device_name_var | 'NUL'}
}
<Предложение MIRROR TO> :: =
ЗЕРКАЛО НА <резервное_устройство> [, ... n]
:: =
{
ФАЙЛ = {логическое_имя_файла | @logical_file_name_var}
| FILEGROUP = {логическая_группа_файлов | @logical_filegroup_name_var}
}
:: =
FILEGROUP = {логическая_группа_файлов | @logical_filegroup_name_var}
[,...n] :: =
- Параметры резервного копирования
COPY_ONLY
| {СЖАТИЕ | NO_COMPRESSION}
| ОПИСАНИЕ = {'текст' | @text_variable}
| NAME = {backup_set_name | @backup_set_name_var}
| ПОЛНОМОЧИЯ
| ШИФРОВАНИЕ
| FILE_SNAPSHOT
| {EXPIREDATE = {'date' | @date_var}
| RETAINDAYS = {дней | @days_var}}
- Параметры набора средств массовой информации
{NOINIT | В ЭТОМ }
| {NOSKIP | ПРОПУСКАТЬ }
| {NOFORMAT | FORMAT}
| MEDIADESCRIPTION = {'текст' | @text_variable}
| MEDIANAME = {media_name | @media_name_variable}
| BLOCKSIZE = {размер блока | @blocksize_variable}
- Параметры передачи данных
BUFFERCOUNT = {buffercount | @buffercount_variable}
| MAXTRANSFERSIZE = {maxtransfersize | @maxtransfersize_variable}
- Параметры управления ошибками
{NO_CHECKSUM | КОНТРОЛЬНАЯ СУММА}
| {STOP_ON_ERROR | CONTINUE_AFTER_ERROR}
- Параметры совместимости
ЗАПУСТИТЬ СНОВА
- Параметры мониторинга
СТАТИСТИКА [= процент]
- Параметры ленты
{НАЗАД | NOREWIND}
| {РАЗГРУЗИТЬ | NOUNLOAD}
- Параметры, относящиеся к журналу
{NORECOVERY | STANDBY = undo_file_name}
| NO_TRUNCATE
- Параметры шифрования
ШИФРОВАНИЕ (АЛГОРИТМ = {AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY}, encryptor_options) :: =
`SERVER CERTIFICATE` = Encryptor_Name | АСИММЕТРИЧЕСКИЙ КЛЮЧ СЕРВЕРА = имя_кодирования
Аргументы
БАЗА ДАННЫХ Задает полную резервную копию базы данных.Если указан список файлов и файловых групп, резервное копирование выполняется только для этих файлов и файловых групп. Во время полного или дифференциального резервного копирования базы данных SQL Server создает резервную копию журнала транзакций, достаточную для создания согласованной базы данных при восстановлении резервной копии.
При восстановлении резервной копии, созданной с помощью BACKUP DATABASE (резервная копия данных ), восстанавливается вся резервная копия. Только резервную копию журнала можно восстановить до определенного времени или транзакции в резервной копии.
Примечание
В базе данных master можно выполнить только полное резервное копирование базы данных.
ЖУРНАЛ
Задает резервную копию только журнала транзакций. Резервное копирование журнала выполняется от последней успешно выполненной резервной копии журнала до текущего конца журнала. Прежде чем вы сможете создать первую резервную копию журнала, вы должны создать полную резервную копию.
Вы можете восстановить резервную копию журнала до определенного времени или транзакции в резервной копии, указав WITH STOPAT , STOPATMARK или STOPBEFOREMARK в операторе RESTORE LOG.
Примечание
После типичного резервного копирования журнала некоторые записи журнала транзакций становятся неактивными, если вы не укажете WITH NO_TRUNCATE или COPY_ONLY .Журнал усекается после того, как все записи в одном или нескольких виртуальных файлах журнала становятся неактивными. Если журнал не усекается после обычного резервного копирования журнала, возможно, что-то задерживает усечение журнала. Дополнительные сведения см. В разделе Факторы, которые могут задерживать усечение журнала.
{ имя_базы_данных | @ database_name_var } База данных, из которой создается резервная копия журнала транзакций, частичной или полной базы данных. Если указано как переменная ( @ переменная имя_базы_данных ), это имя может быть указано либо как строковая константа ( @ переменная_имя_базы_данных = имя базы данных ), либо как переменная типа данных символьной строки, за исключением для типов данных ntext или text .
Примечание
Не удается создать резервную копию зеркальной базы данных в партнерстве зеркального отображения базы данных.
<файл_или группа_файлов> [, … n ] Используется только с BACKUP DATABASE, указывает файл базы данных или файловую группу для включения в резервную копию файла или указывает файл или файловую группу только для чтения для включения в частичную резервную копию.
ФАЙЛ = { имя_логического_файла | @ логическая_имя_файла_варь } Логическое имя файла или переменной, значение которой соответствует логическому имени файла, который должен быть включен в резервную копию.
FILEGROUP = { имя_логической_группы_файлов | @ логический_файл имя_группы_вар } Логическое имя файловой группы или переменной, значение которой соответствует логическому имени файловой группы, которая должна быть включена в резервную копию. В простой модели восстановления резервное копирование файловой группы разрешено только для файловой группы, доступной только для чтения.
Примечание
Рассмотрите возможность использования резервных копий файлов, если размер базы данных и требования к производительности делают резервное копирование базы данных непрактичным.Устройство NUL можно использовать для проверки производительности резервного копирования, но не в производственной среде.
n Заполнитель, который указывает, что в списке, разделенном запятыми, можно указать несколько файлов и файловых групп. Количество не ограничено.
Для получения дополнительной информации см. Полное резервное копирование файлов и Резервное копирование файлов и файловых групп.
READ_WRITE_FILEGROUPS [, FILEGROUP = { имя_логической_группы_файлов | @ логический_файл имя_группы_варь } [, … n ]] Задает частичную резервную копию. Частичная резервная копия включает все файлы для чтения / записи в базе данных: первичную файловую группу и любые вторичные файловые группы для чтения / записи, а также любые указанные файлы или файловые группы, доступные только для чтения.
READ_WRITE_FILEGROUPS Задает резервное копирование всех файловых групп чтения / записи в частичном резервном копировании. Если база данных доступна только для чтения, READ_WRITE_FILEGROUPS включает только первичную файловую группу.
Важно
Явный список файловых групп чтения / записи с использованием FILEGROUP вместо READ_WRITE_FILEGROUPS создает резервную копию файла.
FILEGROUP = { имя_логической_группы_файлов | @ логический_файл имя_группы_вар }
Логическое имя файловой группы, доступной только для чтения, или переменной, значение которой соответствует логическому имени файловой группы, доступной только для чтения, которая должна быть включена в частичную резервную копию. Дополнительную информацию см. В разделе «
n Заполнитель, который указывает, что в списке, разделенном запятыми, можно указать несколько файловых групп, доступных только для чтения.
Для получения дополнительной информации о частичных резервных копиях см. Частичные резервные копии.
TO <резервное_устройство> [, … n ] Указывает, что сопутствующий набор устройств резервного копирования является либо набором без зеркальных носителей, либо первым из зеркал в наборе зеркальных носителей (для которого объявлено одно или несколько предложений MIRROR TO).
<резервное_устройство>
Задает логическое или физическое устройство резервного копирования, используемое для операции резервного копирования.
{ имя_ логического_устройства | @ логическое_имя_устройства_варь } Применимо к: SQL Server Логическое имя устройства резервного копирования, на которое создается резервная копия базы данных.Логическое имя должно соответствовать правилам для идентификаторов. Если задано как переменная (@ логическое_имя_устройства_варь ), имя устройства резервного копирования может быть указано либо как строковая константа (@ логическое_имя_устройства_var = имя логического устройства резервного копирования ), либо как переменная любого типа данных символьной строки, кроме ntext или text типы данных.
{ДИСК | ЛЕНТА | URL} = { ‘ имя_ физического_устройства ‘ | @ физическая_имя_устройства_варь | ‘NUL’} Применимо к: ДИСК, ЛЕНТА и URL-адрес применяются к SQL Server.Задает дисковый файл, ленточное устройство или службу хранилища больших двоичных объектов Microsoft Azure. Формат URL-адреса используется для создания резервных копий в службе хранилища Microsoft Azure. Дополнительные сведения и примеры см. В разделе Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure. Учебник см. В разделе Учебник: Резервное копирование и восстановление SQL Server в службе хранилища BLOB-объектов Microsoft Azure.
Примечание
Дисковое устройство NUL отбрасывает всю отправленную на него информацию, и его следует использовать только для тестирования.Это не для производственного использования.
URL-адрес относится к : SQL Server (SQL Server 2012 (11.x) SP1 CU2 и более поздние версии).
Дисковое устройство не обязательно должно существовать до того, как оно будет указано в операторе BACKUP. Если физическое устройство существует и опция INIT не указана в операторе BACKUP, резервная копия добавляется к устройству.
Примечание
Устройство NUL отбрасывает все входные данные, отправленные в этот файл, однако резервная копия по-прежнему помечает все страницы как резервные.
Для получения дополнительной информации см. Устройства резервного копирования.
Примечание
Параметр TAPE будет удален в будущей версии SQL Server. Избегайте использования этой функции в новых разработках и запланируйте изменение приложений, которые в настоящее время используют эту функцию.
n Заполнитель, который указывает, что в списке, разделенном запятыми, может быть указано до 64 устройств резервного копирования.
ЗЕРКАЛО НА <резервное_устройство> [, … n ] Задает набор до трех вторичных устройств резервного копирования, каждое из которых является зеркалом устройств резервного копирования, указанных в предложении TO.Предложение MIRROR TO должно указывать тот же тип и количество устройств резервного копирования, что и предложение TO. Максимальное количество предложений MIRROR TO — три.
Этот параметр доступен только в версии SQL Server Enterprise.
Примечание
Для MIRROR TO = DISK функция BACKUP автоматически определяет подходящий размер блока для дисковых устройств на основе размера сектора диска. Если диск MIRROR TO отформатирован с размером сектора, отличным от размера диска, указанного в качестве основного устройства резервного копирования, команда резервного копирования завершится ошибкой.Чтобы зеркалировать резервные копии на устройства с разными размерами секторов, необходимо указать параметр BLOCKSIZE, который должен быть установлен на самый высокий размер сектора среди всех целевых устройств. Дополнительные сведения о размере блока см. В разделе «РАЗМЕР БЛОКА» далее в этом разделе.
<резервное_устройство> См. «
n Заполнитель, который указывает, что в списке, разделенном запятыми, может быть указано до 64 устройств резервного копирования. Количество устройств в предложении MIRROR TO должно равняться количеству устройств в предложении TO.
Дополнительные сведения см. В разделе «Семейства носителей в зеркальных наборах носителей» в разделе «Примечания» далее в этом разделе.
[ next-mirror-to ] Заполнитель, который указывает, что один оператор BACKUP может содержать до трех предложений MIRROR TO в дополнение к одному предложению TO.
с опциями
Задает параметры, которые будут использоваться при операции резервного копирования.
ПОЛНОМОЧИЯ Применимо к : SQL Server (SQL Server 2012 (11.x) SP1 CU2 и более поздние версии).Используется только при создании резервной копии в службе хранилища BLOB-объектов Microsoft Azure.
FILE_SNAPSHOT Применимо к : SQL Server (SQL Server 2016 (13.x) и новее).
Используется для создания моментального снимка файлов базы данных Azure, когда все файлы базы данных SQL Server хранятся с помощью службы хранилища BLOB-объектов Azure. Дополнительные сведения см. В разделе Файлы данных SQL Server в Microsoft Azure. Резервное копирование моментальных снимков SQL Server создает моментальные снимки Azure файлов базы данных (файлов данных и журналов) в согласованном состоянии.Согласованный набор моментальных снимков Azure составляет резервную копию и записывается в файл резервной копии. Единственное различие между BACKUP DATABASE TO URL WITH FILE_SNAPSHOT и BACKUP LOG TO URL WITH FILE_SNAPSHOT состоит в том, что последний также усекает журнал транзакций, а первый — нет. При резервном копировании моментальных снимков SQL Server после первоначального полного резервного копирования, которое требуется SQL Server для создания цепочки резервных копий, требуется только одна резервная копия журнала транзакций для восстановления базы данных на момент времени резервного копирования журнала транзакций.Более того, для восстановления базы данных на момент времени между двумя резервными копиями журнала транзакций требуются только две резервные копии журнала транзакций.
ДИФФЕРЕНЦИАЛ
Используется только с BACKUP DATABASE, указывает, что резервная копия базы данных или файла должна состоять только из частей базы данных или файла, измененных с момента последней полной резервной копии. Дифференциальная резервная копия обычно занимает меньше места, чем полная. Используйте эту опцию, чтобы не применять все отдельные резервные копии журналов, выполненные с момента последней полной резервной копии.
Примечание
По умолчанию BACKUP DATABASE создает полную резервную копию.
Для получения дополнительной информации см. Дифференциальное резервное копирование.
ШИФРОВАНИЕ
Используется для указания шифрования для резервной копии. Вы можете указать алгоритм шифрования для шифрования резервной копии или указать NO_ENCRYPTION , чтобы резервная копия не шифровалась. Шифрование рекомендуется для защиты файлов резервных копий. Список алгоритмов, которые вы можете указать:
-
AES_128 -
AES_192 -
AES_256 -
TRIPLE_DES_3KEY -
NO_ENCRYPTION
Если вы выбрали шифрование, вам также необходимо указать шифровальщик с помощью параметров шифрования:
-
СЕРТИФИКАТ СЕРВЕРА= Encryptor_Name -
АСИММЕТРИЧЕСКИЙ КЛЮЧ СЕРВЕРА= Имя_кодирования
СЕРТИФИКАТ СЕРВЕРА и АСИММЕТРИЧНЫЙ КЛЮЧ СЕРВЕРА — это сертификат и асимметричный ключ, созданные в базе данных master .Для получения дополнительной информации см. CREATE CERTIFICATE и CREATE ASYMMETRIC KEY соответственно.
Предупреждение
Когда шифрование используется в сочетании с аргументом FILE_SNAPSHOT , сам файл метаданных шифруется с использованием указанного алгоритма шифрования, и система проверяет, было ли выполнено прозрачное шифрование данных (TDE) для базы данных. Для самих данных дополнительного шифрования не происходит. Резервное копирование не выполняется, если база данных не была зашифрована или если шифрование не было завершено до того, как был выпущен оператор резервного копирования.
Опции резервного набора
Эти параметры работают с набором резервных копий, созданным этой операцией резервного копирования.
Примечание
Чтобы указать набор резервных копий для операции восстановления, используйте параметр FILE = . Дополнительные сведения о том, как указать набор резервных копий, см. В разделе «Указание набора резервных копий» в аргументах RESTORE.
ТОЛЬКО КОПИРОВАНИЕ Указывает, что резервная копия является резервной копией только для копирования , что не влияет на нормальную последовательность резервного копирования.Резервная копия, предназначенная только для копирования, создается независимо от обычного запланированного резервного копирования. Резервное копирование только для копирования не влияет на общие процедуры резервного копирования и восстановления базы данных.
Резервные копии только для копирования следует использовать в ситуациях, когда резервная копия создается для специальных целей, например, для резервного копирования журнала перед восстановлением файла в оперативном режиме. Обычно резервная копия журнала только для копирования используется один раз, а затем удаляется.
При использовании с
BACKUP DATABASEпараметрCOPY_ONLYсоздает полную резервную копию, которая не может служить в качестве разностной базы.Разностная битовая карта не обновляется, а дифференциальные резервные копии ведут себя так, как будто резервная копия только для копирования не существует. Последующие разностные резервные копии используют в качестве основы самую последнюю обычную полную резервную копию.Важно
Если
DIFFERENTIALиCOPY_ONLYиспользуются вместе,COPY_ONLYигнорируется, и создается дифференциальная резервная копия.При использовании с
BACKUP LOGопцияCOPY_ONLYсоздает резервную копию журнала только для копирования , которая не усекает журнал транзакций.Резервная копия журнала только для копирования не влияет на цепочку журналов, а другие резервные копии журналов ведут себя так, как если бы резервная копия только для копирования не существовала.
Для получения дополнительной информации см. Резервные копии только для копирования.
{СЖАТИЕ | NO_COMPRESSION} Только в SQL Server 2008 Enterprise и более поздних версиях указывает, выполняется ли сжатие резервной копии для этой резервной копии, переопределяя значение по умолчанию на уровне сервера.
При установке по умолчанию сжатие резервных копий отсутствует. Но это значение по умолчанию можно изменить, установив параметр конфигурации сервера по умолчанию для сжатия резервных копий.Для получения информации о просмотре текущего значения этого параметра см. Просмотр или изменение свойств сервера.
Информацию об использовании сжатия резервных копий с базами данных с включенным прозрачным шифрованием данных (TDE) см. В разделе «Примечания».
СЖАТИЕ Явно включает сжатие резервных копий.
NO_COMPRESSION Явно отключает сжатие резервных копий.
ОПИСАНИЕ = { ‘ текст ‘ | @ text_variable } Задает текст в произвольной форме, описывающий резервный набор.Строка может содержать максимум 255 символов.
NAME = { backup_set_name | @ backup_set_var } Задает имя резервного набора. Имена могут содержать не более 128 символов. Если ИМЯ не указано, оно пустое.
{EXPIREDATE = ‘ date ‘ | СРОК ДНЕЙ = дней } Указывает, когда резервный набор для этой резервной копии может быть перезаписан. Если используются обе эти опции, RETAINDAYS имеет приоритет над EXPIREDATE.
Если ни одна из опций не указана, срок действия определяется параметром конфигурации mediaretention . Для получения дополнительной информации см. Параметры конфигурации сервера.
Важно
Эти параметры только предотвращают перезапись файла SQL Server. Ленты можно стирать другими способами, а файлы на диске можно удалять через операционную систему. Дополнительные сведения о проверке срока действия см. В разделах ПРОПУСТИТЬ и ФОРМАТИРОВАТЬ в этом разделе.
СРОК СРОКА = { ‘ дата ‘ | @ date_var } Указывает, когда срок действия резервного набора данных истекает и может быть перезаписан.Если указана как переменная (@ date_var ), эта дата должна соответствовать настроенному системному формату datetime и быть указана как одно из следующих:
- Строковая константа (@ date_var = date)
- Переменная типа данных символьная строка (кроме типов данных ntext или text )
- A smalldatetime
- A datetime переменная
Например:
-
'31 декабря 2020 г., 23:59' -
'01.01.2021'
Для получения информации о том, как указать значения datetime , см. Типы даты и времени.
Примечание
Чтобы игнорировать дату истечения срока, используйте опцию ПРОПУСТИТЬ .
СРОК ДНЕЙ = { дней | @ days_var } Задает количество дней, которое должно пройти, прежде чем этот набор носителей резервной копии может быть перезаписан. Если он указан как переменная ( @ days_var ), он должен быть указан как целое число.
Опции набора носителей
Эти параметры действуют для всего набора носителей.
{ NOINIT | В ЭТОМ } Управляет тем, будет ли операция резервного копирования дополнять или перезаписывать существующие наборы резервных копий на носителе резервных копий. По умолчанию добавляется к самому последнему набору резервных копий на носителе (NOINIT).
Примечание
Для получения информации о взаимодействии между { NOINIT | INIT} и { NOSKIP | SKIP}, см. Примечания далее в этом разделе.
NOINIT Указывает, что набор резервных копий добавляется к указанному набору носителей с сохранением существующих наборов резервных копий.Если для набора носителей определен пароль носителя, пароль должен быть предоставлен. NOINIT — значение по умолчанию.
Для получения дополнительной информации см. Наборы носителей, семейства носителей и наборы для резервного копирования.
INIT Указывает, что все наборы резервных копий должны быть перезаписаны, но сохраняет заголовок носителя. Если указан INIT, любой существующий резервный набор на этом устройстве перезаписывается, если позволяют условия. По умолчанию BACKUP проверяет следующие условия и не перезаписывает носитель резервной копии, если существует какое-либо из условий:
- Срок действия любого резервного набора еще не истек.Для получения дополнительной информации см. Параметры
EXPIREDATEиRETAINDAYS. - Имя набора резервных копий, указанное в операторе BACKUP, если оно указано, не совпадает с именем на носителе резервных копий. Для получения дополнительной информации см. Параметр NAME ранее в этом разделе.
Чтобы отменить эти проверки, используйте опцию ПРОПУСТИТЬ .
Для получения дополнительной информации см. Наборы носителей, семейства носителей и наборы для резервного копирования.
{ NOSKIP | ПРОПУСКАТЬ } Определяет, проверяет ли операция резервного копирования дату и время истечения срока действия наборов резервных копий на носителе перед их перезаписью.
Примечание
Для получения информации о взаимодействии между { NOINIT | INIT} и { NOSKIP | SKIP}, см. «Замечания» далее в этом разделе.
НОСКИП Указывает оператору BACKUP проверять дату истечения срока действия всех наборов резервных копий на носителе, прежде чем разрешить их перезапись. Это поведение по умолчанию.
ПРОПУСТИТЬ Отключает проверку истечения срока действия и имени набора резервных копий, которая обычно выполняется оператором BACKUP для предотвращения перезаписи наборов резервных копий.Для получения информации о взаимодействии между {INIT | NOINIT} и {NOSKIP | SKIP}, см. «Замечания» далее в этом разделе. Чтобы просмотреть даты истечения срока действия наборов резервных копий, запросите столбец expiration_date таблицы истории набора резервных копий.
{ NOFORMAT | FORMAT} Указывает, следует ли записывать заголовок носителя на томах, используемых для этой операции резервного копирования, перезаписывая любой существующий заголовок носителя и наборы резервных копий.
NOFORMAT Указывает, что операция резервного копирования сохраняет существующий заголовок носителя и наборы резервных копий на томах носителя, используемых для этой операции резервного копирования.Это поведение по умолчанию.
ФОРМАТ Указывает, что будет создан новый набор носителей. FORMAT заставляет операцию резервного копирования записывать новый заголовок носителя на все тома носителя, используемые для операции резервного копирования. Существующее содержимое тома становится недействительным, поскольку все существующие заголовки носителя и наборы резервных копий перезаписываются.
Важно
Используйте FORMAT осторожно. Форматирование любого тома набора носителей делает непригодным для использования весь набор носителей. Например, если вы инициализируете одну ленту, принадлежащую существующему набору носителей с чередованием, весь набор носителей становится бесполезным.
Указание FORMAT подразумевает SKIP ; SKIP не требует явного указания.
MEDIADESCRIPTION = { текст | @ text_variable } Задает текстовое описание набора носителей в произвольной форме, не более 255 символов.
MEDIANAME = { media_name | @ media_name_variable }
Задает имя носителя для всего набора носителей резервной копии. Имя носителя не должно быть длиннее 128 символов. Если указано MEDIANAME , оно должно совпадать с ранее указанным именем носителя, уже существующим на резервных томах.Если он не указан или если указана опция SKIP, проверка имени носителя не выполняется.
РАЗМЕР БЛОКА = { Размер блока | @ blockize_variable } Задает размер физического блока в байтах. Поддерживаемые размеры: 512, 1024, 2048, 4096, 8192, 16384, 32768 и 65536 (64 КБ) байтов. Значение по умолчанию — 65536 для ленточных устройств и 512 в противном случае. Обычно в этой опции нет необходимости, поскольку BACKUP автоматически выбирает размер блока, соответствующий устройству.Явное указание размера блока отменяет автоматический выбор размера блока.
Если вы делаете резервную копию, которую планируете скопировать и восстановить с компакт-диска, укажите BLOCKSIZE = 2048.
Примечание
Этот параметр обычно влияет на производительность только при записи на ленточные устройства.
Опции передачи данных
BUFFERCOUNT = { buffercount | @ buffercount_variable } Задает общее количество буферов ввода-вывода, которые будут использоваться для операции резервного копирования.Вы можете указать любое положительное целое число; однако большое количество буферов может вызвать ошибки «нехватки памяти» из-за неадекватного виртуального адресного пространства в процессе Sqlservr.exe.
Общее пространство, используемое буферами, определяется следующим образом: BUFFERCOUNT * MAXTRANSFERSIZE .
MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable } Задает наибольшую единицу передачи в байтах, которая будет использоваться между SQL Server и резервным носителем.Возможные значения кратны 65536 байтам (64 КБ) в диапазоне до 4194304 байта (4 МБ).
Примечание
При создании резервных копий с помощью службы SQL Writer, если база данных настроила FILESTREAM или включает файловые группы, оптимизированные для памяти, тогда значение MAXTRANSFERSIZE во время восстановления должно быть больше или равно MAXTRANSFERSIZE , которое использовалось, когда резервная копия была создана.
Примечание
Для баз данных с включенным прозрачным шифрованием данных (TDE) с одним файлом данных значение по умолчанию MAXTRANSFERSIZE равно 65536 (64 КБ).Для баз данных без шифрования TDE значение MAXTRANSFERSIZE по умолчанию составляет 1048576 (1 МБ) при использовании резервного копирования на ДИСК и 65536 (64 КБ) при использовании VDI или TAPE.
Дополнительные сведения об использовании сжатия резервных копий с базами данных с шифрованием TDE см. В разделе «Примечания».
Опции управления ошибками
Эти параметры позволяют определить, включены ли контрольные суммы резервного копирования для операции резервного копирования и останавливается ли операция при обнаружении ошибки.
{ NO_CHECKSUM | КОНТРОЛЬНАЯ СУММА} Управляет включением контрольных сумм резервных копий.
NO_CHECKSUM Явно отключает создание контрольных сумм резервных копий (и проверку контрольных сумм страниц). Это поведение по умолчанию.
КОНТРОЛЬНАЯ СУММА Указывает, что операция резервного копирования проверяет каждую страницу на предмет контрольной суммы и разорванной страницы, если она включена и доступна, и генерирует контрольную сумму для всей резервной копии.
Использование контрольных сумм резервных копий может повлиять на рабочую нагрузку и пропускную способность резервного копирования.
Для получения дополнительной информации см. Возможные ошибки носителя во время резервного копирования и восстановления.
{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR} Определяет, будет ли операция резервного копирования остановлена или продолжена после обнаружения ошибки контрольной суммы страницы.
STOP_ON_ERROR Дает команду BACKUP завершиться неудачей, если контрольная сумма страницы не проверяется. Это поведение по умолчанию.
CONTINUE_AFTER_ERROR Дает указание продолжить РЕЗЕРВНОЕ КОПИРОВАНИЕ, несмотря на обнаружение таких ошибок, как неверные контрольные суммы или порванные страницы.
Если вы не можете выполнить резервное копирование хвостовой части журнала с помощью опции NO_TRUNCATE, когда база данных повреждена, вы можете попытаться выполнить резервное копирование хвостового журнала, указав CONTINUE_AFTER_ERROR вместо NO_TRUNCATE.
Для получения дополнительной информации см. Возможные ошибки носителя во время резервного копирования и восстановления.
Варианты совместимости
ПЕРЕЗАГРУЗИТЬ Начиная с SQL Server 2008, не действует. Эта опция принята версией для совместимости с предыдущими версиями SQL Server.
Опции мониторинга
СТАТИСТИКА[ = в процентах ] Отображает сообщение каждый раз, когда выполняется еще процентов, завершается и используется для оценки прогресса. Если процентов опущено, SQL Server отображает сообщение после завершения каждых 10 процентов.
Параметр STATS сообщает процент завершения от порогового значения для сообщения следующего интервала. Это примерно указанный процент; например, при STATS = 10, если завершенная сумма составляет 40 процентов, опция может отображать 43 процента. Для больших наборов резервных копий это не проблема, потому что процент завершения очень медленно перемещается между завершенными вызовами ввода-вывода.
Опции ленты
Эти параметры используются только для устройств TAPE. Если используется устройство без ленты, эти параметры игнорируются.
{ REWIND | NOREWIND} НАЗАД
Указывает, что SQL Server освобождает и перематывает ленту. НАЗАД — по умолчанию.
НОРВИНД
Указывает, что SQL Server будет держать ленту открытой после операции резервного копирования. Этот параметр можно использовать для повышения производительности при выполнении нескольких операций резервного копирования на ленту.
NOREWIND подразумевает NOUNLOAD, и эти параметры несовместимы в одном операторе BACKUP.
Примечание
Если вы используете NOREWIND , экземпляр SQL Server сохраняет право собственности на ленточный накопитель до тех пор, пока оператор BACKUP или RESTORE, выполняемый в том же процессе, не использует параметр REWIND или UNLOAD , либо экземпляр сервера не будет закрыт вниз.Если лента остается открытой, это предотвращает доступ к ней других процессов. Для получения информации о том, как отобразить список открытых лент и закрыть открытую ленту, см. Устройства резервного копирования.
{ ВЫГРУЗКА | NOUNLOAD}
Примечание
UNLOAD и NOUNLOAD — это параметры сеанса, которые сохраняются в течение всего сеанса или до тех пор, пока он не будет сброшен путем указания альтернативы.
РАЗГРУЗИТЬ
Указывает, что лента автоматически перематывается и выгружается после завершения резервного копирования.UNLOAD — это значение по умолчанию, когда начинается сеанс.
NOUNLOAD
Указывает, что после операции РЕЗЕРВНОЕ КОПИРОВАНИЕ лента остается загруженной в ленточный накопитель.
Примечание
Для резервного копирования на ленточное устройство резервного копирования параметр BLOCKSIZE влияет на производительность операции резервного копирования. Этот параметр обычно влияет на производительность только при записи на ленточные устройства.
Параметры журнала
Эти параметры используются только с BACKUP LOG .
Примечание
Если вы не хотите создавать резервные копии журналов, используйте простую модель восстановления. Для получения дополнительной информации см. Модели восстановления.
{NORECOVERY | STANDBY = undo_file_name }
NORECOVERY
Создает резервную копию конца журнала и оставляет базу данных в состоянии ВОССТАНОВЛЕНИЕ. NORECOVERY полезен при переключении на вторичную базу данных или при сохранении хвоста журнала перед операцией RESTORE.
Чтобы выполнить максимально возможное резервное копирование журнала, которое пропускает усечение журнала и затем атомарно переводит базу данных в состояние ВОССТАНОВЛЕНИЕ, используйте параметры NO_TRUNCATE и NORECOVERY вместе.
STANDBY = имя_файла ожидания
Создает резервную копию конца журнала и оставляет базу данных в состоянии только для чтения и в режиме ожидания. Предложение STANDBY записывает данные в режиме ожидания (выполняется откат, но с возможностью дальнейшего восстановления). Использование опции STANDBY эквивалентно BACKUP LOG WITH NORECOVERY с последующим RESTORE WITH STANDBY.
Для использования режима ожидания необходим резервный файл, указанный в имя_файла_остановления , расположение которого сохраняется в журнале базы данных.Если указанный файл уже существует, компонент Database Engine перезаписывает его; если файл не существует, компонент Database Engine создает его. Резервный файл становится частью базы данных.
В этом файле хранятся откатные изменения, которые необходимо отменить, если впоследствии будут применяться операции RESTORE LOG. На диске должно быть достаточно места для увеличения резервного файла, чтобы он мог содержать все отдельные страницы из базы данных, которые были изменены путем отката незафиксированных транзакций.
NO_TRUNCATE
Указывает, что журнал не усекается, и заставляет компонент Database Engine предпринимать попытки резервного копирования независимо от состояния базы данных. Следовательно, резервная копия, сделанная с помощью NO_TRUNCATE , может иметь неполные метаданные. Эта опция позволяет создать резервную копию журнала в ситуациях, когда база данных повреждена.
Параметр NO_TRUNCATE в BACKUP LOG эквивалентен указанию COPY_ONLY и CONTINUE_AFTER_ERROR.
Без опции NO_TRUNCATE база данных должна находиться в состоянии ONLINE.Если база данных находится в состоянии SUSPENDED, вы можете создать резервную копию, указав NO_TRUNCATE . Но если база данных находится в состоянии OFFLINE или EMERGENCY, BACKUP не разрешено даже с NO_TRUNCATE . Для получения информации о состояниях базы данных см. Состояния базы данных.
О работе с резервными копиями SQL Server
В этом разделе представлены следующие основные концепции резервного копирования:
Типы резервного копирования Усечение журнала транзакций Форматирование носителя с резервной копией Работа с устройствами резервного копирования и наборами носителей Восстановление резервных копий SQL Server
Типы резервных копий
Поддерживаемые типы резервного копирования зависят от модели восстановления базы данных, а именно
Все модели восстановления поддерживают полное и дифференциальное резервное копирование данных.
Объем резервного копирования Типы резервных копий Вся база Резервные копии базы данных охватывают всю базу данных. При желании каждая резервная копия базы данных может служить основой для серии из одной или нескольких разностных резервных копий базы данных.
Неполная база данных Частичные резервные копии охватывают файловые группы для чтения / записи и, возможно, один или несколько файлов или файловых групп, предназначенных только для чтения. Дополнительно каждая частичная резервная копия может служить основой для серии из одной или нескольких дифференциальных частичных резервных копий.
Файл или файловая группа Резервные копии файлов охватывают один или несколько файлов или файловых групп и актуальны только для баз данных, содержащих несколько файловых групп. В рамках простой модели восстановления резервное копирование файлов по существу ограничено вторичными файловыми группами, доступными только для чтения.
По желанию, каждая резервная копия файла может служить основой для серии из одной или нескольких разностных резервных копий файлов.При модели полного восстановления или модели восстановления с неполным протоколированием обычные резервные копии также включают последовательные резервные копии журналов транзакций (или резервные копии журналов ), которые необходимы.Каждая резервная копия журнала охватывает ту часть журнала транзакций, которая была активной на момент создания резервной копии, и включает в себя все записи журнала, резервные копии которых не были созданы в предыдущей резервной копии журнала.
Чтобы свести к минимуму вероятность потери работы за счет административных накладных расходов, следует запланировать частое резервное копирование журналов. Планирование дифференциального резервного копирования между полными резервными копиями может сократить время восстановления за счет уменьшения количества резервных копий журналов, которые необходимо восстановить после восстановления данных.
Мы рекомендуем размещать резервные копии журналов на отдельном томе, а не резервные копии базы данных.
Примечание
Перед созданием первой резервной копии журнала необходимо создать полную резервную копию.
Резервная копия только для копирования — это специальная полная резервная копия или резервная копия журнала, которая не зависит от нормальной последовательности обычных резервных копий. Чтобы создать резервную копию только для копирования, укажите параметр COPY_ONLY в операторе BACKUP. Дополнительные сведения см. В разделе Резервные копии только для копирования.
Усечение журнала транзакций
Чтобы избежать переполнения журнала транзакций базы данных, необходимо регулярное резервное копирование.В простой модели восстановления усечение журнала происходит автоматически после резервного копирования базы данных, а в модели полного восстановления — после резервного копирования журнала транзакций. Однако иногда процесс усечения может затягиваться. Для получения информации о факторах, которые могут задержать усечение журнала, см. Журнал транзакций.
Примечание
Опции BACKUP LOG WITH NO_LOG и WITH TRUNCATE_ONLY больше не поддерживаются. Если вы используете модель восстановления с полным или неполным протоколированием и вам необходимо удалить цепочку резервных копий журналов из базы данных, переключитесь на простую модель восстановления.Дополнительные сведения см. В разделе Просмотр или изменение модели восстановления базы данных.
Форматирование носителя с резервной копией
Резервный носитель форматируется оператором BACKUP тогда и только тогда, когда выполняется одно из следующих условий:
- Опция
FORMATуказана. - Носитель пуст.
- Операция записывает продолжение ленты.
Работа с устройствами резервного копирования и наборами носителей
Устройства резервного копирования в наборе чередующихся носителей (чередующийся набор)
Набор полос — это набор файлов на диске, на которых данные разделены на блоки и распределены в фиксированном порядке.Количество устройств резервного копирования, используемых в наборе чередования, должно оставаться неизменным (если только носитель не инициализирован повторно с помощью FORMAT ).
В следующем примере выполняется запись резервной копии базы данных AdventureWorks2012 на новый чередующийся набор носителей, который использует три дисковых файла.
РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks2012
НА ДИСК = 'X: \ SQLServerBackups \ AdventureWorks1.bak',
DISK = 'Y: \ SQLServerBackups \ AdventureWorks2.bak',
ДИСК = 'Z: \ SQLServerBackups \ AdventureWorks3.bak'
С ФОРМАТОМ,
MEDIANAME = 'AdventureWorksStripedSet0',
MEDIADESCRIPTION = 'Полосатый набор мультимедиа для базы данных AdventureWorks2012';
ИДТИ
После того, как устройство резервного копирования определено как часть чередующегося набора, его нельзя использовать для резервного копирования одного устройства, если не указан FORMAT.Точно так же устройство резервного копирования, которое содержит незаполненные резервные копии, не может использоваться в наборе чередования, если не указан FORMAT. Чтобы разделить чередующийся набор резервных копий, используйте FORMAT.
Если при записи медиа-заголовка не указано ни MEDIANAME, ни MEDIADESCRIPTION, поле медиа-заголовка, соответствующее пустому элементу, будет пустым.
Работа с зеркальным набором носителей
Обычно резервные копии не являются зеркальными, а операторы BACKUP просто включают предложение TO. Однако на один набор носителей можно установить до четырех зеркал.Для зеркального набора носителей операция резервного копирования записывает на несколько групп устройств резервного копирования. Каждая группа устройств резервного копирования состоит из одного зеркала в зеркальном наборе носителей. Каждое зеркало должно использовать одинаковое количество и тип физических устройств резервного копирования, которые должны иметь одинаковые свойства.
Для резервного копирования на зеркальный набор носителей должны присутствовать все зеркала. Чтобы выполнить резервное копирование на зеркальный набор носителей, укажите предложение TO , чтобы указать первое зеркало, и укажите предложение MIRROR TO для каждого дополнительного зеркала.
Для зеркального набора носителей каждое предложение MIRROR TO должно указывать то же количество и тип устройств, что и предложение TO. В следующем примере выполняется запись в зеркальный набор носителей, который содержит два зеркала и использует три устройства на зеркало:
РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks2012
НА ДИСК = 'X: \ SQLServerBackups \ AdventureWorks1a.bak',
ДИСК = 'Y: \ SQLServerBackups \ AdventureWorks2a.bak',
ДИСК = 'Z: \ SQLServerBackups \ AdventureWorks3a.bak'
ЗЕРКАЛО НА ДИСК = 'X: \ SQLServerBackups \ AdventureWorks1b.бак ',
ДИСК = 'Y: \ SQLServerBackups \ AdventureWorks2b.bak',
ДИСК = 'Z: \ SQLServerBackups \ AdventureWorks3b.bak';
ИДТИ
Важно
Этот пример разработан, чтобы вы могли протестировать его в вашей локальной системе. На практике резервное копирование на несколько устройств на одном диске снизит производительность и устранит избыточность, для которой предназначены зеркальные наборы носителей.
Семейства носителей в зеркальных наборах носителей
Каждое устройство резервного копирования, указанное в разделе TO оператора BACKUP, соответствует семейству носителей.Например, если в разделах с по перечислены три устройства, BACKUP записывает данные в три семейства носителей. В зеркальном наборе носителей каждое зеркало должно содержать копию каждого семейства носителей. Поэтому количество устройств в каждом зеркале должно быть одинаковым.
Если для каждого зеркала указано несколько устройств, их порядок определяет, какое семейство носителей записывается на конкретное устройство. Например, в каждом из списков устройств второе устройство соответствует второму семейству носителей.Для устройств в приведенном выше примере соответствие между устройствами и семействами носителей показано в следующей таблице.
| Зеркало | Семейство носителей 1 | Семейство носителей 2 | Семейство носителей 3 |
|---|---|---|---|
| 0 | Z: \ AdventureWorks1a.bak | Z: \ AdventureWorks2a.bak | Z: \ AdventureWorks3a.bak |
| 1 | Z: \ AdventureWorks1b.бак | Z: \ AdventureWorks2b.bak | Z: \ AdventureWorks3b.bak |
Семейство носителей всегда должно копироваться на одно и то же устройство в определенном зеркале. Поэтому каждый раз, когда вы используете существующий набор носителей, перечисляйте устройства каждого зеркала в том же порядке, в каком они были указаны при создании набора носителей.
Для получения дополнительной информации о зеркальных наборах носителей см. Зеркальные наборы носителей для резервного копирования. Дополнительные сведения о наборах носителей и семействах носителей в целом см. В разделах «Наборы носителей, семейства носителей и наборы для резервного копирования».
Восстановление резервных копий SQL Server
Чтобы восстановить базу данных и, при необходимости, восстановить ее для перевода в оперативный режим или для восстановления файла или файловой группы, используйте оператор Transact-SQL RESTORE или задачи SQL Server Management Studio Restore . Для получения дополнительной информации см. Восстановление и обзор восстановления.
Дополнительные сведения о параметрах РЕЗЕРВНОГО КОПИРОВАНИЯ
Взаимодействие SKIP, NOSKIP, INIT и NOINIT
В этой таблице описывается взаимодействие между { NOINIT | INIT} и { NOSKIP | SKIP} варианты.
Примечание
Если ленточный носитель пуст или файл резервной копии диска не существует, все эти взаимодействия записывают заголовок носителя и продолжаются. Если носитель не пустой и у него отсутствует допустимый заголовок носителя, эти операции выдают обратную связь о том, что это недопустимый носитель MTF, и завершают операцию резервного копирования.
| Пропустить вариант | НОИНИТ | ИНИТ |
|---|---|---|
| NOSKIP | Если том содержит допустимый заголовок носителя, проверяет соответствие имени носителя заданному MEDIANAME , если таковое имеется.Если он совпадает, добавляет резервный набор, сохраняя все существующие резервные наборы. Если том не содержит допустимого заголовка носителя, возникает ошибка. | Если том содержит допустимый заголовок носителя, выполняет следующие проверки:
Если эти проверки пройдены, перезаписывает все наборы резервных копий на носителе, сохраняя только заголовок носителя. Если том не содержит допустимого заголовка носителя, генерирует его с использованием указанных MEDIANAME и MEDIADESCRIPTION , если таковые имеются. |
| ПРОПУСТИТЬ | Если том содержит допустимый заголовок носителя, добавляет резервный набор, сохраняя все существующие резервные наборы. | Если том содержит допустимый заголовок носителя 2 , перезаписывает все наборы резервных копий на носителе, сохраняя только заголовок носителя. Если носитель пуст, генерирует заголовок носителя, используя указанные MEDIANAME и MEDIADESCRIPTION , если таковые имеются. |
1 Для выполнения операции резервного копирования пользователь должен принадлежать к соответствующей фиксированной роли базы данных или сервера.
2 Срок действия включает номер версии MTF и другую информацию заголовка. Если указанная версия не поддерживается или имеет неожиданное значение, возникает ошибка.
Совместимость
Осторожно
Резервные копии, созданные более поздней версией SQL Server, не могут быть восстановлены в более ранних версиях SQL Server.
BACKUP поддерживает опцию RESTART для обеспечения обратной совместимости с более ранними версиями SQL Server. Но ПЕРЕЗАГРУЗКА не имеет никакого эффекта.
Общие замечания
Резервные копии базы данных или журналов могут быть добавлены на любой диск или ленточное устройство, что позволяет хранить базу данных и ее журналы транзакций в одном физическом месте.
Оператор BACKUP не разрешен в явной или неявной транзакции.
Межплатформенные операции резервного копирования, даже между разными типами процессоров, могут выполняться, если упорядочение базы данных поддерживается операционной системой.
Начиная с SQL Server 2016 (13.x), установка MAXTRANSFERSIZE больше 65536 (64 КБ) включает оптимизированный алгоритм сжатия для зашифрованных баз данных с прозрачным шифрованием данных (TDE), который сначала расшифровывает страницу, сжимает ее, а затем снова шифрует его. Если MAXTRANSFERSIZE не указано или используется MAXTRANSFERSIZE = 65536 (64 КБ), сжатие резервных копий с базами данных с шифрованием TDE непосредственно сжимает зашифрованные страницы и может не дать хороших коэффициентов сжатия.Дополнительные сведения см. В разделе Сжатие резервных копий для баз данных с поддержкой TDE.
Начиная с SQL Server 2019 (15.x) CU5, установка MAXTRANSFERSIZE больше не требуется для включения этого оптимизированного алгоритма сжатия с TDE. Если задана команда резервного копирования WITH COMPRESSION или конфигурация сервера по умолчанию для сжатия резервных копий установлена на 1, MAXTRANSFERSIZE будет автоматически увеличено до 128 КБ для включения оптимизированного алгоритма. Если MAXTRANSFERSIZE указано в команде резервного копирования со значением> 64 КБ, предоставленное значение будет учтено.Другими словами, SQL Server никогда не уменьшит значение автоматически, а только увеличит его. Если вам нужно создать резервную копию зашифрованной базы данных TDE с MAXTRANSFERSIZE = 65536 , вы должны указать WITH NO_COMPRESSION или убедиться, что для конфигурации сервера сжатия резервных копий по умолчанию установлено значение 0.
Примечание
В некоторых случаях значение по умолчанию MAXTRANSFERSIZE больше 64 КБ:
- Когда в базе данных создано несколько файлов данных, используется
MAXTRANSFERSIZE> 64K - При выполнении резервного копирования на URL-адрес по умолчанию
MAXTRANSFERSIZE = 1048576(1 МБ)
Даже если выполняется одно из этих условий, вы должны явно установить MAXTRANSFERSIZE больше 64 КБ в своей команде резервного копирования, чтобы получить оптимизированный алгоритм сжатия резервных копий, если вы не используете SQL Server 2019 (15.x) CU5 или новее.
По умолчанию каждая успешная операция резервного копирования добавляет запись в журнал ошибок SQL Server и в журнал системных событий. Если выполнять резервное копирование журнала очень часто, эти сообщения об успешном выполнении накапливаются быстро, что приводит к появлению огромных журналов ошибок, которые могут затруднить поиск других сообщений. В таких случаях вы можете подавить эти записи журнала с помощью флага трассировки 3226, если ни один из ваших сценариев не зависит от этих записей. Для получения дополнительной информации см. Флаги трассировки.
Взаимодействие
SQL Server использует процесс оперативного резервного копирования, чтобы разрешить резервное копирование базы данных, пока база данных еще используется.Во время резервного копирования возможно большинство операций; например, операторы INSERT, UPDATE или DELETE разрешены во время операции резервного копирования.
Операции, которые нельзя запустить во время резервного копирования базы данных или журнала транзакций, включают:
Операции управления файлами, такие как оператор
ALTER DATABASEс опциямиADD FILEилиREMOVE FILE.Операции сжатия базы данных или файла. Сюда входят операции автоматического сжатия.
Если операция резервного копирования перекрывается с операцией управления файлами или сжатия, возникает конфликт. Независимо от того, какая из конфликтующих операций началась первой, вторая операция ожидает тайм-аута блокировки, установленной первой операцией (период тайм-аута управляется настройкой тайм-аута сеанса). Если блокировка снимается в течение периода ожидания, вторая операция продолжается. Если время блокировки истекло, вторая операция завершится ошибкой.
SQL Server включает следующие таблицы журнала резервного копирования, которые отслеживают активность резервного копирования:
При выполнении восстановления, если набор резервных копий еще не был записан в базе данных msdb , таблицы истории резервного копирования могут быть изменены.
Безопасность
Начиная с SQL Server 2012 (11.x), параметры ПАРОЛЬ и MEDIAPASSWORD больше не используются для создания резервных копий. По-прежнему возможно восстановление резервных копий, созданных с помощью паролей.
Разрешения
РазрешенияBACKUP DATABASE и BACKUP LOG по умолчанию для членов фиксированной роли сервера sysadmin и фиксированных ролей базы данных db_owner и db_backupoperator .
Проблемы с правами собственности и разрешения на физический файл устройства резервного копирования могут помешать операции резервного копирования.SQL Server должен иметь возможность читать и писать на устройство; учетная запись, под которой запускается служба SQL Server, должна иметь разрешения на запись. Однако процедура sp_addumpdevice, которая добавляет запись для устройства резервного копирования в системные таблицы, не проверяет права доступа к файлам. Такие проблемы с физическим файлом устройства резервного копирования могут не появиться до тех пор, пока к физическому ресурсу не будет осуществлен доступ при попытке резервного копирования или восстановления.
Примеры
Этот раздел содержит следующие примеры:
Примечание
Разделы с практическими рекомендациями по резервному копированию содержат дополнительные примеры.Для получения дополнительной информации см. Обзор резервного копирования.
A. Резервное копирование полной базы данных
В следующем примере выполняется резервное копирование базы данных AdventureWorks2012 в файл на диске.
РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks2012
НА ДИСК = 'Z: \ SQLServerBackups \ AdvWorksData.bak'
С ФОРМАТОМ;
ИДТИ
B. Резервное копирование базы данных и журнала
В следующем примере выполняется резервное копирование образца базы данных AdventureWorks2012 , в которой по умолчанию используется простая модель восстановления.Для поддержки резервного копирования журналов база данных AdventureWorks2012 модифицирована для использования модели полного восстановления.
Далее в примере используется процедура sp_addumpdevice для создания логического устройства резервного копирования для резервного копирования данных, AdvWorksData , и создается другое логическое устройство резервного копирования для резервного копирования журнала, AdvWorksLog .
Затем в примере создается полная резервная копия базы данных на AdvWorksData , а после периода активности обновления создается резервная копия журнала на AdvWorksLog .
- Чтобы разрешить резервное копирование журнала, перед полным резервным копированием базы данных измените базу данных
- использовать модель полного восстановления.
Мастер ИСПОЛЬЗОВАНИЯ;
ИДТИ
ИЗМЕНИТЬ БАЗУ ДАННЫХ AdventureWorks2012
УСТАНОВИТЬ ВОССТАНОВЛЕНИЕ ПОЛНОЕ;
ИДТИ
- Создание логических устройств резервного копирования AdvWorksData и AdvWorksLog.
ИСПОЛЬЗУЙТЕ мастер
ИДТИ
EXEC sp_addumpdevice 'disk', 'AdvWorksData',
'Z: \ SQLServerBackups \ AdvWorksData.bak';
ИДТИ
EXEC sp_addumpdevice 'disk', 'AdvWorksLog',
'X: \ SQLServerBackups \ AdvWorksLog.bak';
ИДТИ
- Сделайте резервную копию полной базы данных AdventureWorks2012.РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks2012 TO AdvWorksData;
ИДТИ
- Сделайте резервную копию журнала AdventureWorks2012.
РЕЗЕРВНЫЙ ЖУРНАЛ AdventureWorks2012
TO AdvWorksLog;
ИДТИ
Примечание
Для производственной базы данных регулярно выполняйте резервное копирование журнала. Резервное копирование журналов должно выполняться достаточно часто, чтобы обеспечить достаточную защиту от потери данных.
C. Создание полной резервной копии файлов вторичных файловых групп
В следующем примере создается полная резервная копия каждого файла в обеих дополнительных файловых группах.
- резервное копирование файлов в SalesGroup1:
РЕЗЕРВНАЯ БАЗА ДАННЫХ Продажи
FILEGROUP = 'Группа продаж1',
FILEGROUP = 'SalesGroup2'
НА ДИСК = 'Z: \ SQLServerBackups \ SalesFiles.bck';
ИДТИ
D. Создание разностной резервной копии файлов вторичных файловых групп
В следующем примере создается разностная резервная копия каждого файла в обеих вторичных файловых группах.
- резервное копирование файлов в SalesGroup1:
РЕЗЕРВНАЯ БАЗА ДАННЫХ Продажи
FILEGROUP = 'Группа продаж1',
FILEGROUP = 'SalesGroup2'
НА ДИСК = 'Z: \ SQLServerBackups \ SalesFiles.bck '
С УЧАСТИЕМ
ДИФФЕРЕНЦИАЛЬНЫЙ;
ИДТИ
E. Создание и резервное копирование на набор зеркальных носителей для одного семейства
В следующем примере создается зеркальный набор носителей, содержащий одно семейство носителей и четыре зеркала, и выполняется резервное копирование на них базы данных AdventureWorks2012 .
РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks2012
К ЛЕНТЕ = '\\. \ Tape0'
ЗЕРКАЛО НА ЛЕНТУ = '\\. \ Tape1'
ЗЕРКАЛО НА ЛЕНТУ = '\\. \ Tape2'
ЗЕРКАЛО НА ЛЕНТЕ = '\\. \ Tape3'
С УЧАСТИЕМ
ФОРМАТ,
MEDIANAME = 'AdventureWorksSet0';
Ф.Создание и резервное копирование на многосемейный зеркальный набор носителей
В следующем примере создается зеркальный набор носителей, в котором каждое зеркало состоит из двух семейств носителей. Затем в примере выполняется резервное копирование базы данных AdventureWorks2012 на оба зеркала.
РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks2012
TO TAPE = '\\. \ Tape0', TAPE = '\\. \ Tape1'
ЗЕРКАЛО НА ЛЕНТЕ = '\\. \ Tape2', TAPE = '\\. \ Tape3'
С УЧАСТИЕМ
ФОРМАТ,
MEDIANAME = 'AdventureWorksSet1';
G. Резервное копирование на существующий зеркальный набор носителей
В следующем примере резервный набор добавляется к набору носителей, созданному в предыдущем примере.
РЕЗЕРВНЫЙ ЖУРНАЛ AdventureWorks2012
TO TAPE = '\\. \ Tape0', TAPE = '\\. \ Tape1'
ЗЕРКАЛО НА ЛЕНТЕ = '\\. \ Tape2', TAPE = '\\. \ Tape3'
С УЧАСТИЕМ
NOINIT,
MEDIANAME = 'AdventureWorksSet1';
Примечание
NOINIT, который используется по умолчанию, показан здесь для ясности.
H. Создание сжатой резервной копии на новом наборе носителей
В следующем примере выполняется форматирование носителя, создание нового набора носителей и выполнение сжатого полного резервного копирования базы данных AdventureWorks2012 .
РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks2012 НА ДИСК = 'Z: \ SQLServerBackups \ AdvWorksData.bak'
С УЧАСТИЕМ
ФОРМАТ,
СЖАТИЕ;
I. Резервное копирование в службу хранилища BLOB-объектов Microsoft Azure
В этом примере выполняется полное резервное копирование базы данных Sales в службу хранилища BLOB-объектов Microsoft Azure. Имя учетной записи хранения — mystorageaccount . Контейнер называется myfirstcontainer . Создана сохраненная политика доступа с правами на чтение, запись, удаление и список.Учетные данные SQL Server https://mystorageaccount.blob.core.windows.net/myfirstcontainer были созданы с использованием подписи общего доступа, связанной с сохраненной политикой доступа. Для получения информации о резервном копировании SQL Server в службу хранилища BLOB-объектов Microsoft Azure см. Разделы Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure и Резервное копирование SQL Server по URL-адресу.
РЕЗЕРВНАЯ БАЗА ДАННЫХ Продажи
К URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_20160726.бак '
СО СТАТИСТИКОЙ = 5;
J. Отслеживать ход выполнения резервного копирования
Следующий запрос возвращает информацию о запущенных в данный момент операторах резервного копирования:
SELECT query = a.text, start_time, percent_complete,
eta = dateadd (секунда, приблизительное_время завершения / 1000, getdate ())
ОТ sys.dm_exec_requests r
ПЕРЕКРЕСТИТЬ ПРИМЕНИТЬ sys.dm_exec_sql_text (r.sql_handle) a
ГДЕ r.command LIKE 'BACKUP%'
См. Также
* Управляемый экземпляр SQL *
Управляемый экземпляр SQL Azure
Выполняет резервное копирование базы данных SQL в управляемом экземпляре SQL Azure.Управляемый экземпляр SQL имеет автоматическое резервное копирование. Вы можете создать полную базу данных COPY_ONLY резервных копий. Дифференциальные резервные копии, резервные копии журналов и моментальных снимков файлов не поддерживаются.
Это также относится к управляемому экземпляру SQL с поддержкой Azure Arc.
Синтаксис
РЕЗЕРВНАЯ БАЗА ДАННЫХ {имя_базы_данных | @database_name_var}
TO URL = {'имя_ физического_устройства' | @physical_device_name_var} [, ... n]
WITH COPY_ONLY [, {}]
[;]
[,...n] :: =
- Параметры набора средств массовой информации
MEDIADESCRIPTION = {'текст' | @text_variable}
| MEDIANAME = {media_name | @media_name_variable}
| BLOCKSIZE = {размер блока | @blocksize_variable}
- Параметры передачи данных
BUFFERCOUNT = {buffercount | @buffercount_variable}
| MAXTRANSFERSIZE = {maxtransfersize | @maxtransfersize_variable}
- Параметры управления ошибками
{NO_CHECKSUM | КОНТРОЛЬНАЯ СУММА}
| {STOP_ON_ERROR | CONTINUE_AFTER_ERROR}
- Параметры совместимости
ЗАПУСТИТЬ СНОВА
- Параметры мониторинга
СТАТИСТИКА [= процент]
- Параметры шифрования
ШИФРОВАНИЕ (АЛГОРИТМ = {AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY}, encryptor_options) :: =
СЕРТИФИКАТ СЕРВЕРА = Encryptor_Name | АСИММЕТРИЧЕСКИЙ КЛЮЧ СЕРВЕРА = имя_кодирования
Аргументы
БАЗА ДАННЫХ Задает полную резервную копию базы данных.Во время резервного копирования базы данных управляемый экземпляр SQL Azure создает резервную копию журнала транзакций, достаточную для создания согласованной базы данных при восстановлении резервной копии.
Важно
Резервную копию базы данных, созданную на управляемом экземпляре, можно восстановить только на другом управляемом экземпляре SQL Azure. Его нельзя восстановить в локальном экземпляре SQL Server (аналогично тому, как резервная копия базы данных SQL Server 2016 не может быть восстановлена в экземпляре SQL Server 2012).
При восстановлении резервной копии, созданной с помощью BACKUP DATABASE (резервная копия данных ), восстанавливается вся резервная копия.Чтобы восстановить из автоматических резервных копий управляемого экземпляра SQL, см. Восстановление базы данных в управляемый экземпляр.
{ имя_базы_данных | @ database_name_var } База данных, из которой создается резервная копия всей базы данных. Если указано как переменная ( @ переменная имя_базы_данных ), это имя может быть указано либо как строковая константа ( @ переменная_имя_базы_данных = имя базы данных ), либо как переменная типа данных символьной строки, за исключением для типов данных ntext или text .
Для получения дополнительной информации см. Полное резервное копирование файлов и Резервное копирование файлов и файловых групп.
К URL
Задает URL-адрес, используемый для операции резервного копирования. Формат URL-адреса используется для создания резервных копий в службе хранилища Microsoft Azure.
n Заполнитель, который указывает, что в списке, разделенном запятыми, может быть указано до 64 устройств резервного копирования.
WITH Options Определяет параметры, которые будут использоваться с операцией резервного копирования.
ПОЛНОМОЧИЯ Используется только при создании резервной копии в службе хранилища BLOB-объектов Microsoft Azure.
ШИФРОВАНИЕ
Используется для указания шифрования для резервной копии. Вы можете указать алгоритм шифрования для шифрования резервной копии или указать NO_ENCRYPTION , чтобы резервная копия не шифровалась. Шифрование рекомендуется для защиты файлов резервных копий. Список алгоритмов, которые вы можете указать:
-
AES_128 -
AES_192 -
AES_256 -
TRIPLE_DES_3KEY -
NO_ENCRYPTION
Если вы выбрали шифрование, вам также необходимо указать шифровальщик, используя параметры шифрования:
-
СЕРТИФИКАТ СЕРВЕРА = <Имя шифратора> -
АСИММЕТРИЧЕСКИЙ КЛЮЧ СЕРВЕРА = <Имя шифратора>
Опции резервного набора
ТОЛЬКО КОПИРОВАНИЕ Указывает, что резервная копия является резервной копией только для копирования , что не влияет на нормальную последовательность резервного копирования.Резервная копия только для копирования создается независимо от автоматических резервных копий Базы данных SQL Azure. Дополнительные сведения см. В разделе Резервные копии только для копирования.
{СЖАТИЕ | NO_COMPRESSION} Указывает, выполняется ли сжатие резервной копии для этой резервной копии, отменяя значение по умолчанию на уровне сервера.
По умолчанию сжатие резервных копий отсутствует. Но это значение по умолчанию можно изменить, установив параметр конфигурации сервера по умолчанию для сжатия резервных копий. Для получения информации о просмотре текущего значения этого параметра см. Просмотр или изменение свойств сервера.
СЖАТИЕ Явно включает сжатие резервных копий.
NO_COMPRESSION Явно отключает сжатие резервных копий.
ОПИСАНИЕ = { ‘ текст ‘ | @ text_variable } Задает текст в произвольной форме, описывающий резервный набор. Строка может содержать максимум 255 символов.
NAME = { backup_set_name | @ backup_set_var } Задает имя резервного набора.Имена могут содержать не более 128 символов. Если ИМЯ не указано, оно пустое.
MEDIADESCRIPTION = { текст | @ text_variable } Задает текстовое описание набора носителей в произвольной форме, не более 255 символов.
MEDIANAME = { media_name | @ media_name_variable }
Задает имя носителя для всего набора носителей резервной копии. Имя носителя не должно быть длиннее 128 символов. Если указано MEDIANAME , оно должно совпадать с ранее указанным именем носителя, уже существующим на резервных томах.Если он не указан или если указана опция SKIP, проверка имени носителя не выполняется.
РАЗМЕР БЛОКА = { Размер блока | @ blockize_variable } Задает размер физического блока в байтах. Поддерживаемые размеры: 512, 1024, 2048, 4096, 8192, 16384, 32768 и 65536 (64 КБ) байтов. Значение по умолчанию — 65536 для ленточных устройств и 512 в противном случае. Обычно в этой опции нет необходимости, поскольку BACKUP автоматически выбирает размер блока, соответствующий устройству.Явное указание размера блока отменяет автоматический выбор размера блока.
Опции передачи данных
BUFFERCOUNT = { buffercount | @ buffercount_variable } Задает общее количество буферов ввода-вывода, которые будут использоваться для операции резервного копирования. Вы можете указать любое положительное целое число; однако большое количество буферов может вызвать ошибки «нехватки памяти» из-за неадекватного виртуального адресного пространства в Sqlservr.exe-процесс.
Общее пространство, используемое буферами, определяется следующим образом: BUFFERCOUNT * MAXTRANSFERSIZE .
MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable } Задает наибольшую единицу передачи в байтах, которая будет использоваться между SQL Server и резервным носителем. Возможные значения кратны 65536 байтам (64 КБ) в диапазоне до 4194304 байта (4 МБ).
Примечание
Для баз данных с включенным прозрачным шифрованием данных (TDE) с одним файлом данных значение по умолчанию MAXTRANSFERSIZE равно 65536 (64 КБ).Для баз данных без шифрования TDE значение MAXTRANSFERSIZE по умолчанию составляет 1048576 (1 МБ) при использовании резервного копирования на ДИСК и 65536 (64 КБ) при использовании VDI или TAPE.
Опции управления ошибками
Эти параметры позволяют определить, включены ли контрольные суммы резервного копирования для операции резервного копирования и останавливается ли операция при обнаружении ошибки.
{ NO_CHECKSUM | КОНТРОЛЬНАЯ СУММА} Управляет включением контрольных сумм резервных копий.
NO_CHECKSUM Явно отключает создание контрольных сумм резервных копий (и проверку контрольных сумм страниц).Это поведение по умолчанию.
КОНТРОЛЬНАЯ СУММА Указывает, что операция резервного копирования проверяет каждую страницу на предмет контрольной суммы и разорванной страницы, если она включена и доступна, и генерирует контрольную сумму для всей резервной копии.
Использование контрольных сумм резервных копий может повлиять на рабочую нагрузку и пропускную способность резервного копирования.
Для получения дополнительной информации см. Возможные ошибки носителя во время резервного копирования и восстановления.
{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR} Определяет, будет ли операция резервного копирования остановлена или продолжена после обнаружения ошибки контрольной суммы страницы.
STOP_ON_ERROR Дает команду BACKUP завершиться неудачей, если контрольная сумма страницы не проверяется. Это поведение по умолчанию.
CONTINUE_AFTER_ERROR Дает указание продолжить РЕЗЕРВНОЕ КОПИРОВАНИЕ, несмотря на обнаружение таких ошибок, как неверные контрольные суммы или порванные страницы.
Если вы не можете выполнить резервное копирование хвостовой части журнала с помощью опции NO_TRUNCATE, когда база данных повреждена, вы можете попытаться выполнить резервное копирование хвостового журнала, указав CONTINUE_AFTER_ERROR вместо NO_TRUNCATE.
Для получения дополнительной информации см. Возможные ошибки носителя во время резервного копирования и восстановления.
Варианты совместимости
ПЕРЕЗАГРУЗИТЬ Не имеет никакого эффекта. Эта опция принята версией для совместимости с предыдущими версиями SQL Server.
Опции мониторинга
СТАТИСТИКА[ = в процентах ] Отображает сообщение каждый раз, когда выполняется еще процентов, завершается и используется для оценки прогресса. Если процентов опущено, SQL Server отображает сообщение после завершения каждых 10 процентов.
Параметр STATS сообщает процент завершения от порогового значения для сообщения следующего интервала. Это примерно указанный процент; например, при STATS = 10, если завершенная сумма составляет 40 процентов, опция может отображать 43 процента. Для больших наборов резервных копий это не проблема, потому что процент завершения очень медленно перемещается между завершенными вызовами ввода-вывода.
Ограничения для управляемого экземпляра SQL
Максимальный размер полосы резервной копии составляет 195 ГБ (максимальный размер большого двоичного объекта).Увеличьте количество полос в команде резервного копирования, чтобы уменьшить размер отдельных полос и не выходить за этот предел.
Безопасность
Разрешения
РазрешенияBACKUP DATABASE по умолчанию для членов фиксированной роли сервера sysadmin и фиксированных ролей базы данных db_owner и db_backupoperator .
Проблемы с правами собственности и разрешения на URL-адрес могут помешать операции резервного копирования. SQL Server должен иметь возможность читать и писать на устройство; учетная запись, под которой запускается служба SQL Server, должна иметь разрешения на запись.
Примеры
В этом примере выполняется резервное копирование COPY_ONLY Sales в службу хранилища BLOB-объектов Microsoft Azure. Имя учетной записи хранения — mystorageaccount . Контейнер называется myfirstcontainer . Создана сохраненная политика доступа с правами на чтение, запись, удаление и список. Учетные данные SQL Server https://mystorageaccount.blob.core.windows.net/myfirstcontainer были созданы с использованием подписи общего доступа, связанной с сохраненной политикой доступа.Для получения информации о резервном копировании SQL Server в службу хранилища BLOB-объектов Microsoft Azure см. Разделы Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure и Резервное копирование SQL Server по URL-адресу.
РЕЗЕРВНАЯ БАЗА ДАННЫХ Продажи
К URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_20160726.bak'
СО СТАТИСТИКОЙ = 5, ТОЛЬКО КОПИРОВАНИЕ;
См. Также
Восстановить базу данных
Восстановление резервной копии базы данных с помощью SSMS — SQL Server
- 14 минут на чтение
В этой статье
Применимо к: SQL Server (все поддерживаемые версии)
В этом разделе объясняется, как восстановить полную резервную копию базы данных с помощью SQL Server Management Studio.
Важно!
Прежде чем вы сможете восстановить базу данных в рамках модели восстановления с полным или неполным протоколированием, вам может потребоваться создать резервную копию активного журнала транзакций (известного как хвост журнала. Дополнительные сведения см. В разделе Резервное копирование журнала транзакций (SQL Server).
При восстановлении базы данных из другого экземпляра учитывайте информацию из раздела «Управление метаданными при обеспечении доступности базы данных на другом экземпляре сервера (SQL Server)».
Чтобы восстановить зашифрованную базу данных, вам необходим доступ к сертификату или асимметричному ключу, используемому для шифрования этой базы данных.Без сертификата или асимметричного ключа вы не сможете восстановить эту базу данных. Сохраните сертификат, используемый для шифрования ключа шифрования базы данных, столько времени, сколько потребуется для сохранения резервной копии. Дополнительные сведения см. В разделе Сертификаты и асимметричные ключи SQL Server.
Если вы восстановите базу данных более старой версии до SQL Server 2019 (15.x), эта база данных автоматически обновится до SQL Server 2019 (15.x). Это предотвращает использование базы данных с более старой версией компонента Database Engine. Однако это относится к обновлению метаданных и не влияет на уровень совместимости базы данных.Если уровень совместимости пользовательской базы данных перед обновлением равен 100 или выше, он остается таким же после обновления. Если перед обновлением уровень совместимости равен 90, в обновленной базе данных уровень совместимости установлен на 100, что является самым низким поддерживаемым уровнем совместимости в SQL Server 2019 (15.x). Дополнительные сведения см. В разделе Уровень совместимости ALTER DATABASE (Transact-SQL).
Обычно база данных становится доступной сразу. Однако, если база данных SQL Server 2005 (9.x) имеет полнотекстовые индексы, процесс обновления импортирует, сбрасывает или перестраивает индексы в зависимости от значения свойства сервера Full-Text Upgrade Option .Если вы установите для параметра обновления значение Import или Rebuild , полнотекстовые индексы будут недоступны во время обновления. В зависимости от объема индексируемых данных импорт может занять несколько часов; восстановление займет до 10 раз больше времени.
При установке параметра обновления на Импорт , если полнотекстовый каталог недоступен, связанные полнотекстовые индексы перестраиваются. Для получения информации о просмотре или изменении настройки свойства Full-Text Upgrade Option см. Управление и мониторинг полнотекстового поиска для экземпляра сервера.
Сведения о восстановлении SQL Server из службы хранилища BLOB-объектов Microsoft Azure см. В разделе Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure.
Примеры
A. Восстановить полную резервную копию базы данных
В обозревателе объектов подключитесь к экземпляру ядра СУБД SQL Server, а затем разверните этот экземпляр.
Щелкните правой кнопкой мыши Базы данных и выберите Восстановить базу данных …
На странице Общие используйте раздел Источник , чтобы указать источник и расположение наборов резервных копий для восстановления.Выберите один из следующих вариантов:
База данных
Выберите базу данных для восстановления из раскрывающегося списка. Список содержит только базы данных, для которых была создана резервная копия в соответствии с историей резервного копирования msdb .
Примечание
Если резервная копия сделана с другого сервера, на целевом сервере не будет информации об истории резервного копирования для указанной базы данных. В этом случае выберите Device , чтобы вручную указать файл или устройство для восстановления.
Устройство
Нажмите кнопку обзора ( … ), чтобы открыть диалоговое окно Выбрать устройства резервного копирования .
Выбор устройств резервного копирования диалоговое окно
Тип носителя резервной копии
Выберите тип носителя из раскрывающегося списка Тип носителя резервной копии . Примечание. Параметр Tape появляется только в том случае, если к компьютеру подключен ленточный накопитель, а параметр Backup Device появляется только в том случае, если существует хотя бы одно устройство резервного копирования.Добавить
В зависимости от типа носителя, который вы выбираете в раскрывающемся списке Тип носителя резервной копии , при нажатии Добавить открывается одно из следующих диалоговых окон. (Если список в поле списка Резервный носитель заполнен, кнопка Добавить будет недоступна.)Тип носителя Диалоговое окно Описание Файл Найти файл резервной копии В этом диалоговом окне вы можете выбрать локальный файл из дерева или указать удаленный файл, используя его полное имя в соответствии с универсальным соглашением об именах (UNC).Дополнительные сведения см. В разделе Устройства резервного копирования (SQL Server). Устройство Выбрать устройство резервного копирования В этом диалоговом окне вы можете выбрать из списка логических устройств резервного копирования, определенных на экземпляре сервера. Лента Выбрать резервную ленту В этом диалоговом окне вы можете выбрать из списка ленточных накопителей, которые физически подключены к компьютеру, на котором запущен экземпляр SQL Server. URL Выберите расположение файла резервной копии В этом диалоговом окне вы можете выбрать существующие учетные данные SQL Server / контейнер хранилища Azure, добавить новый контейнер хранилища Azure с общей подписью доступа или сгенерировать общую подпись доступа и учетные данные SQL Server для существующего контейнера хранилища. См. Также Подключение к подписке Microsoft Azure Удалить
Удаляет один или несколько выбранных файлов, лент или логических устройств резервного копирования.Содержание
Отображает содержимое носителя для выбранного файла, ленты или логического устройства резервного копирования. Эта кнопка может не работать, если тип носителя — URL .Резервный носитель
Показывает выбранный носитель.После добавления устройств, которые необходимо добавить в список Носитель резервной копии , нажмите ОК , чтобы вернуться на страницу Общие .
В списке Источник: Устройство: База данных выберите имя базы данных, которую необходимо восстановить.
Примечание
Этот список доступен, только если выбрано Устройство . Будут доступны только базы данных, резервные копии которых есть на выбранном устройстве.
В разделе Назначение поле База данных автоматически заполняется именем восстанавливаемой базы данных. Чтобы изменить имя базы данных, введите новое имя в поле База данных .
В поле « Restore to » оставьте значение по умолчанию . Для последней созданной резервной копии или щелкните Timeline , чтобы открыть диалоговое окно Backup Timeline , чтобы вручную выбрать момент времени для остановки действия восстановления.Дополнительные сведения о выборе определенного момента времени см. В разделе Временная шкала резервного копирования.
В Резервные наборы для восстановления сетки выберите резервные копии для восстановления. В этой сетке отображаются резервные копии, доступные для указанного места. По умолчанию предлагается план восстановления. Чтобы отменить предложенный план восстановления, вы можете изменить выбор в сетке. Резервные копии, которые зависят от восстановления более ранней резервной копии, автоматически отменяются, когда отменяется выбор более ранней резервной копии.Для получения информации о столбцах в наборах резервных копий для восстановления сетки см. Восстановление базы данных (страница «Общие»).
При желании щелкните Файлы на панели Выберите страницу , чтобы открыть диалоговое окно Файлы . Отсюда вы можете восстановить базу данных в новое место, указав новое место назначения для каждого файла в Восстановить файлы базы данных как сетку . Дополнительные сведения об этой сетке см. В разделе Восстановление базы данных (страница файлов).
Для просмотра или выбора дополнительных параметров на странице Параметры на панели Параметры восстановления вы можете выбрать любой из следующих параметров, если это подходит для вашей ситуации:
- С опциями (не требуется):
Заменить существующую базу данных (ЗАМЕНА)
Сохранить настройки репликации (WITH KEEP_REPLICATION)
Ограничить доступ к восстановленной базе данных (WITH RESTRICTED_USER)
- Выберите параметр для поля Состояние восстановления .Это поле определяет состояние базы данных после операции восстановления.
ВОССТАНОВЛЕНИЕ С ВОССТАНОВЛЕНИЕМ — это поведение по умолчанию, при котором база данных остается готовой к использованию путем отката незафиксированных транзакций. Никакие дополнительные журналы транзакций не могут быть восстановлены. Выберите этот вариант, если сейчас вы восстанавливаете все необходимые резервные копии.
RESTORE WITH NORECOVERY , который оставляет базу данных неработоспособной и не откатывает незафиксированные транзакции.Можно восстановить дополнительные журналы транзакций. Базу данных нельзя использовать, пока она не будет восстановлена.
ВОССТАНОВЛЕНИЕ В РЕЖИМЕ ОЖИДАНИЯ , при котором база данных остается в режиме только для чтения. Он отменяет незавершенные транзакции, но сохраняет отмененные действия в резервном файле, чтобы можно было отменить эффекты восстановления.
Сделайте резервную копию конечного журнала перед восстановлением. Не для всех сценариев восстановления требуется резервная копия конечного журнала. Для получения дополнительной информации см. Сценарии, требующие резервного копирования хвостового журнала из резервных копий хвостового журнала (SQL Server).
Операции восстановления могут завершиться ошибкой, если есть активные подключения к базе данных. Установите флажок « Закрыть существующие подключения» , чтобы убедиться, что все активные подключения между Management Studio и базой данных закрыты. Этот флажок устанавливает базу данных в однопользовательский режим перед операциями восстановления и устанавливает базу данных в многопользовательский режим после завершения.
Выберите Запрашивать перед восстановлением каждой резервной копии. , если вы хотите получать подсказки между каждой операцией восстановления.В этом нет необходимости, если база данных не велика и вы не хотите отслеживать статус операции восстановления.
Дополнительные сведения об этих параметрах восстановления см. В разделе Восстановление базы данных (страница параметров).
- Щелкните ОК .
B. Восстановить предыдущую резервную копию диска поверх существующей базы данных
В следующем примере восстанавливается предыдущая резервная копия диска Sales и перезаписывается существующая база данных Sales .
В обозревателе объектов подключитесь к экземпляру ядра СУБД SQL Server, а затем разверните этот экземпляр.
Щелкните правой кнопкой мыши Базы данных и выберите Восстановить базу данных …
На странице General выберите Device в разделе Source .
Нажмите кнопку обзора ( … ), чтобы открыть диалоговое окно Выбрать устройства резервного копирования .Щелкните Добавить и перейдите к своей резервной копии. Нажмите OK после того, как вы выбрали файл (ы) резервной копии диска.
Нажмите ОК , чтобы вернуться на страницу Общие .
Щелкните Параметры на панели Выберите страницу .
В разделе Параметры восстановления отметьте Перезаписать существующую базу данных (С ЗАМЕНИТЬЮ) .
Примечание
Если не установить этот флажок, может появиться следующее сообщение об ошибке: «System.Data.SqlClient.SqlError: набор резервных копий содержит резервную копию базы данных, отличной от существующей базы данных «
Sales». (Microsoft.SqlServer.SmoExtended) «В разделе Резервное копирование хвостового журнала снимите флажок Создавать резервную копию конечного журнала перед восстановлением .
Примечание
Не для всех сценариев восстановления требуется резервная копия конечного журнала. Вам не нужна резервная копия хвостового журнала, если точка восстановления содержится в более ранней резервной копии журнала. Кроме того, в резервной копии хвостового журнала нет необходимости, если вы перемещаете или заменяете (перезаписываете) базу данных и вам не нужно восстанавливать ее до определенного момента времени после последней резервной копии.Дополнительные сведения см. В разделе Резервное копирование хвостового журнала (SQL Server).
Этот параметр недоступен для баз данных в модели восстановления ПРОСТОЙ.
В разделе Соединения с сервером отметьте Закройте существующие соединения с целевой базой данных .
Примечание
Отсутствие проверки этого параметра может привести к появлению следующего сообщения об ошибке: «System.Data.SqlClient.SqlError: монопольный доступ не может быть получен, поскольку база данных уже используется.(Microsoft.SqlServer.SmoExtended) «
Щелкните ОК .
C. Восстановить предыдущую резервную копию диска с новым именем базы данных, где исходная база данных все еще существует
В следующем примере восстанавливается предыдущая резервная копия диска Sales и создается новая база данных с именем SalesTest . Исходная база данных Sales все еще существует на сервере.
В обозревателе объектов подключитесь к экземпляру ядра СУБД SQL Server, а затем разверните этот экземпляр.
Щелкните правой кнопкой мыши Базы данных и выберите Восстановить базу данных …
На странице General выберите Device в разделе Source .
Нажмите кнопку обзора ( … ), чтобы открыть диалоговое окно Выбрать устройства резервного копирования . Щелкните Добавить и перейдите к своей резервной копии. Нажмите OK после того, как вы выбрали файл (ы) резервной копии диска.
Нажмите ОК , чтобы вернуться на страницу Общие .
В разделе Назначение поле База данных автоматически заполняется именем восстанавливаемой базы данных. Чтобы изменить имя базы данных, введите новое имя в поле База данных .
Щелкните Параметры на панели Выберите страницу .
В разделе Резервное копирование хвостового журнала снимите флажок « Сделать резервную копию хвостового журнала перед восстановлением ».
Важно
Если не снять этот флажок, существующая база данных
Salesперейдет в состояние восстановления.Щелкните ОК .
Примечание
Если вы получаете следующее сообщение об ошибке:
«System.Data.SqlClient.SqlError: хвостовая часть журнала для базы данных«Sales»не была скопирована. ИспользуйтеBACKUP LOG WITH NORECOVERYдля резервного копирования журнала, если он содержит работу, которую вы не хотите терять.Используйте предложениеWITH REPLACEилиWITH STOPATоператораRESTORE, чтобы просто перезаписать содержимое журнала. (Microsoft.SqlServer.SmoExtended) «.
Тогда вы, вероятно, не ввели имя новой базы данных из шага 6 выше. Восстановление обычно предотвращает случайную перезапись базы данных другой базой данных. Если база данных, указанная в оператореRESTORE, уже существует на текущем сервере и указанный GUID семейства баз данных отличается от GUID семейства баз данных, записанного в резервном наборе, база данных не восстанавливается.Это важная гарантия.
D. Восстановление на момент времени
В следующем примере база данных восстанавливается до состояния по состоянию на 13:23:17 PM 30 мая 2016 г. и показывает операцию восстановления, которая включает в себя несколько резервных копий журналов. База данных в настоящее время не существует на сервере.
- В обозревателе объектов подключитесь к экземпляру ядра СУБД SQL Server, а затем разверните этот экземпляр.
- Щелкните правой кнопкой мыши Базы данных и выберите Восстановить базу данных…
- На странице General выберите Device в разделе Source .
- Нажмите кнопку обзора ( … ), чтобы открыть диалоговое окно Выбрать устройства резервного копирования . Щелкните Добавить и перейдите к своей полной резервной копии и всем соответствующим резервным копиям журналов транзакций. Нажмите OK после того, как вы выбрали файлы резервной копии диска.
- Нажмите ОК , чтобы вернуться на страницу Общие .
- В разделе Назначение щелкните Временная шкала , чтобы открыть диалоговое окно Временная шкала резервного копирования , чтобы вручную выбрать момент времени для остановки действия восстановления.
- Выберите Определенная дата и время .
- Измените интервал временной шкалы с на час в раскрывающемся списке (необязательно).
- Переместите ползунок на желаемое время.
- Нажмите ОК , чтобы вернуться на страницу «Общие».
- Щелкните ОК .
E. Восстановить резервную копию из службы хранилища Microsoft Azure
Общие шаги
В двух приведенных ниже примерах выполняется восстановление Sales из резервной копии, расположенной в службе хранилища Microsoft Azure.Имя учетной записи хранения — mystorageaccount . Контейнер называется myfirstcontainer . Для краткости первые шесть шагов перечислены здесь один раз, и все примеры начинаются с , шаг 7, .
- В обозревателе объектов подключитесь к экземпляру ядра СУБД SQL Server, а затем разверните этот экземпляр.
- Щелкните правой кнопкой мыши Базы данных и выберите Восстановить базу данных … .
- На странице General выберите Device в разделе Source .
- Нажмите кнопку обзора (…), чтобы открыть диалоговое окно Выбрать устройства резервного копирования .
- Выберите URL из раскрывающегося списка Тип носителя резервной копии: .
- Щелкните Добавить , и откроется диалоговое окно «Выбор расположения файла резервной копии ».
E1. Восстановите чередующуюся резервную копию существующей базы данных, если существует общая подпись доступа.
Создана сохраненная политика доступа с правами на чтение, запись, удаление и список.Подпись общего доступа, связанная с сохраненной политикой доступа, была создана для контейнера https://mystorageaccount.blob.core.windows.net/myfirstcontainer . Шаги в основном такие же, если учетные данные SQL Server уже существуют. База данных Продажи в настоящее время существует на сервере. Файлы резервных копий: Sales_stripe1of2_20160601.bak и Sales_stripe2of2_20160601.bak .
- Выберите
https: // mystorageaccount.blob.core.windows.net/myfirstcontainerиз контейнера хранилища Azure : раскрывающийся список , если учетные данные SQL Server уже существуют, иначе вручную введите имя контейнера,https: //mystorageaccount.blob.core. windows.net/myfirstcontainer. - Введите подпись общего доступа в поле Shared Access Signature: RTF.
- Нажмите ОК , и откроется диалоговое окно Найти файл резервной копии в Microsoft Azure .
- Разверните Контейнеры и перейдите к
https://mystorageaccount.blob.core.windows.net/myfirstcontainer. - Удерживая Ctrl, выберите файлы
Sales_stripe1of2_20160601.bakиSales_stripe2of2_20160601.bak. - Щелкните ОК .
- Нажмите ОК , чтобы вернуться на страницу Общие .
- Щелкните Параметры на панели Выберите страницу .
- В разделе опций Restore отметьте Перезаписать существующую базу данных (WITH REPLACE) .
- В разделе Резервное копирование хвостового журнала снимите флажок Создавать резервную копию хвостового журнала перед восстановлением .
- В разделе Соединения с сервером отметьте Закройте существующие соединения с целевой базой данных .
- Щелкните ОК .
E2. Подпись общего доступа не существует
В этом примере база данных Sales в настоящее время не существует на сервере.
- Щелкните Добавить , и откроется диалоговое окно Подключиться к подписке Microsoft .
- Заполните диалоговое окно «Подключение к подписке Microsoft », а затем нажмите ОК, , чтобы вернуться в диалоговое окно « Выберите расположение файла резервной копии» . Дополнительные сведения см. В разделе Подключение к подписке Microsoft Azure.
- Нажмите ОК в диалоговом окне Выбор расположения файла резервной копии , и откроется диалоговое окно Найти файл резервной копии в Microsoft Azure .
- Разверните Контейнеры и перейдите к
https: // mystorageaccount.blob.core.windows.net/myfirstcontainer. - Выберите файл резервной копии и нажмите ОК .
- Нажмите ОК , чтобы вернуться на страницу Общие .
- Щелкните ОК .
F. Восстановление локальной резервной копии в хранилище Microsoft Azure (URL-адрес)
База данных Sales будет восстановлена в контейнер хранилища Microsoft Azure https://mystorageaccount.blob.core.windows.net/myfirstcontainer из резервной копии, расположенной по адресу E: \ MSSQL \ BAK .Учетные данные SQL Server для контейнера Azure уже созданы. Учетные данные SQL Server для целевого контейнера уже должны существовать, поскольку их нельзя создать с помощью задачи Restore . База данных Sales в настоящее время не существует на сервере.
- В обозревателе объектов подключитесь к экземпляру ядра СУБД SQL Server, а затем разверните этот экземпляр.
- Щелкните правой кнопкой мыши Базы данных и выберите Восстановить базу данных… .
- На странице General выберите Device в разделе Source .
- Нажмите кнопку обзора (…), чтобы открыть диалоговое окно Выбрать устройства резервного копирования .
- Выберите Файл из раскрывающегося списка Тип носителя резервной копии: .
- Щелкните Добавить , откроется диалоговое окно Найти файл резервной копии .
- Перейдите к
E: \ MSSQL \ BAK, выберите файл резервной копии и нажмите ОК . - Нажмите ОК , чтобы вернуться на страницу Общие .
- Щелкните Файлы на панели Выберите страницу .
- Установите флажок Переместите все файлы в папку .
- Введите контейнер
https://mystorageaccount.blob.core.windows.net/myfirstcontainerв текстовые поля для Папка файлов данных: и Папка файлов журнала: . - Щелкните ОК .
См. Также
Резервное копирование журнала транзакций (SQL Server)
Создание полной резервной копии базы данных (SQL Server)
Восстановление базы данных в новом месте (SQL Server)
Восстановление резервной копии журнала транзакций (SQL Server)
ВОССТАНОВЛЕНИЕ (Transact-SQL)
Восстановить базу данных (страница параметров)
Восстановить базу данных (страница «Общие»)
Дифференциальное резервное копирование — SQL Server
- 5 минут на чтение
В этой статье
Применимо к: SQL Server (все поддерживаемые версии)
Создайте дифференциальную резервную копию базы данных в SQL Server с помощью SQL Server Management Studio или Transact-SQL.
Разделов в теме
Прежде чем начать
Ограничения и ограничения
- Оператор BACKUP не разрешен в явной или неявной транзакции.
Предварительные требования
- Для создания разностной резервной копии базы данных требуется предыдущая полная резервная копия базы данных. Если для вашей базы данных никогда не выполнялось резервное копирование, запустите полное резервное копирование базы данных перед созданием любых дифференциальных резервных копий. Дополнительные сведения см. В разделе Создание полной резервной копии базы данных (SQL Server).
Рекомендации
- По мере увеличения размера дифференциальных резервных копий восстановление из дифференциальной резервной копии значительно увеличивает время, необходимое для восстановления базы данных. Мы рекомендуем вам делать новую полную резервную копию через заданные интервалы, чтобы создать новую разностную базу для данных. Например, вы можете делать еженедельное полное резервное копирование всей базы данных (то есть полную резервную копию базы данных), за которым следует регулярная серия разностных резервных копий базы данных в течение недели.
Безопасность
Сначала проверьте свои разрешения!
РазрешенияBACKUP DATABASE и BACKUP LOG по умолчанию для членов фиксированной роли сервера sysadmin , фиксированных ролей базы данных db_owner и db_backupoperator .
Проблемы с правами собственности и правами доступа к физическому файлу устройства резервного копирования могут помешать операции резервного копирования. SQL Server должен иметь возможность читать и писать на устройство; учетная запись, под которой запускается служба SQL Server, должна иметь разрешения на запись.Однако процедура sp_addumpdevice, которая добавляет запись для устройства резервного копирования в системные таблицы, не проверяет права доступа к файлам , а не . Проблемы с разрешениями для физического файла устройства резервного копирования не будут очевидны до тех пор, пока к физическому ресурсу не будет осуществлен доступ при попытке резервного копирования или восстановления.
Студия управления SQL Server
Создание разностной резервной копии базы данных
После подключения к соответствующему экземпляру ядра СУБД Microsoft SQL Server в обозревателе объектов щелкните имя сервера, чтобы развернуть дерево серверов.
Разверните Базы данных и, в зависимости от базы данных, либо выберите базу данных пользователя, либо разверните Системные базы данных и выберите системную базу данных.
Щелкните базу данных правой кнопкой мыши, выберите Задачи , а затем щелкните Резервное копирование . Откроется диалоговое окно Резервное копирование базы данных .
В списке База данных проверьте имя базы данных. При желании вы можете выбрать другую базу данных из списка.
Вы можете выполнить дифференциальное резервное копирование для любой модели восстановления (полного, с неполным протоколированием или простого).
В списке Тип резервной копии выберите Дифференциальный .
Важно
При выборе Дифференциальный убедитесь, что флажок Копировать только резервную копию снят.
Для компонента резервного копирования щелкните База данных .
Либо примите имя набора резервных копий по умолчанию, предложенное в текстовом поле Имя , либо введите другое имя для набора резервных копий.
При желании в текстовом поле Описание введите описание резервного набора.
Укажите, когда истечет срок действия резервного набора:
Чтобы срок действия резервного набора данных истек через определенное количество дней, щелкните После (вариант по умолчанию) и введите количество дней после создания набора, в течение которого срок действия набора истечет. Это значение может быть от 0 до 99999 дней; 0 дней означает, что срок действия резервного набора никогда не истечет.
Значение по умолчанию устанавливается в параметре Хранение резервного носителя по умолчанию (в днях) диалогового окна Свойства сервера (страница Параметры базы данных ).Чтобы получить к нему доступ, щелкните правой кнопкой мыши имя сервера в обозревателе объектов и выберите свойства; затем выберите страницу Настройки базы данных .
Чтобы срок действия набора резервных копий истек в определенную дату, щелкните На и введите дату истечения срока действия набора.
Выберите тип места назначения резервной копии, щелкнув Диск или Лента . Чтобы выбрать путь до 64 дисков или ленточных накопителей, содержащих один набор носителей, щелкните Добавить .Выбранные пути отображаются в списке « Backup to ».
Чтобы удалить место назначения резервной копии, выберите его и нажмите Удалить . Чтобы просмотреть содержимое места назначения резервной копии, выберите его и щелкните Содержание .
Чтобы просмотреть или выбрать дополнительные параметры, щелкните Параметры на панели Выбрать страницу .
Выберите опцию Overwrite Media , щелкнув одно из следующего:
Резервное копирование к существующему набору носителей
Для этого параметра щелкните Добавить к существующему набору резервных копий или Перезаписать все существующие наборы резервных копий .При желании установите флажок Проверить имя набора носителей и срок действия набора резервных копий и, при желании, введите имя в текстовое поле Имя набора носителей . Если имя не указано, создается набор носителей с пустым именем. Если вы указываете имя набора носителей, носитель (лента или диск) проверяется, чтобы увидеть, совпадает ли фактическое имя с именем, которое вы вводите здесь.
Если вы оставите имя носителя пустым и установите флажок, чтобы сопоставить его с носителем, успех будет равным тому, что имя носителя на носителе также будет пустым.
Резервное копирование на новый набор носителей и удаление всех существующих наборов резервных копий
Для этого параметра введите имя в текстовое поле Имя нового набора носителей и, при необходимости, опишите набор носителей в текстовом поле Описание нового набора носителей .
В разделе «Надежность », по желанию, отметьте:
Если вы выполняете резервное копирование на ленточный накопитель (как указано в разделе Назначение на странице Общие ), Выгрузить ленту после резервного копирования активна опция .При выборе этой опции активируется опция «Перемотать ленту перед выгрузкой» .
Примечание
Параметры в разделе журнала транзакций неактивны, если вы не выполняете резервное копирование журнала транзакций (как указано в разделе Тип резервной копии на странице Общие ).
SQL Server 2008 Enterprise и более поздних версий поддерживает сжатие резервных копий. По умолчанию сжатие резервной копии зависит от значения параметра конфигурации сервера по умолчанию для резервного копирования и сжатия .Однако, независимо от текущего значения по умолчанию на уровне сервера, вы можете сжать резервную копию, установив флажок Сжать резервную копию , и вы можете предотвратить сжатие, установив флажок Не сжимать резервную копию .
Для просмотра текущего значения сжатия резервной копии по умолчанию
Примечание
В качестве альтернативы можно использовать мастер плана обслуживания для создания разностных резервных копий базы данных.
Transact-SQL
Создание разностной резервной копии базы данных
Выполните оператор BACKUP DATABASE для создания разностной резервной копии базы данных, указав:
Имя базы данных для резервного копирования.
Устройство резервного копирования, на которое записывается полная резервная копия базы данных.
Предложение DIFFERENTIAL, указывающее, что резервное копирование выполняется только для тех частей базы данных, которые изменились после создания последней полной резервной копии базы данных.
Требуемый синтаксис:
РЕЗЕРВНАЯ БАЗА ДАННЫХ имя_базы_данных НА <резервное_устройство> С ДИФФЕРЕНЦИАЛОМ
Пример (Transact-SQL)
В этом примере создается полная и дифференциальная резервная копия базы данных MyAdvWorks .
- Сначала создайте полную резервную копию базы данных.
РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ MyAdvWorks
В MyAdvWorks_1
ВНУТРИ;
ИДТИ
- Время идет.
- Создать дифференциальную резервную копию базы данных, добавив резервную копию
- на устройство резервного копирования, содержащее полную резервную копию базы данных.
РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ MyAdvWorks
В MyAdvWorks_1
С ДИФФЕРЕНЦИАЛОМ;
ИДТИ
См. Также
Дифференциальное резервное копирование (SQL Server)
Создание полной резервной копии базы данных (SQL Server)
Резервное копирование файлов и файловых групп (SQL Server)
Восстановление дифференциальной резервной копии базы данных (SQL Server)
Восстановление резервной копии журнала транзакций (SQL Server)
Планы обслуживания
Полное резервное копирование файлов (SQL Server)
SQL Server, резервные копии MySQL и PostgreSQL
Резервное копирование базы данных за 2 мин.
Нет более сложной конфигурации, только одна форма для автоматизации резервного копирования: выбор баз данных, резервное копирование (полное, сравнение, журнал передачи), шифрование, сжатие, отправка в папку, FTP или облачный сервис:
планирует резервное копирование, получать электронные письма с подтверждением и восстанавливать при необходимости.
Характеристики и ценыот $ 0
бесплатно — резервное копирование 2 баз данных в сеть или FTP по расписанию
$ 39 + резервное копирование 5 баз данных, Google Drive или Dropbox
$ 89 + неограниченное резервное копирование базы данных, OneDrive Personal и Box
129 долларов США + Amazon S3, Windows Azure, OneDrive для бизнеса и шифрование AES
$ 499 + пожизненные обновления
Что умеет SQLBackupAndFTP?
SQLBackupAndFTP — это программное обеспечение, которое выполняет резервное копирование баз данных SQL Server, MySQL и PostgreSQL Server, выполняет регулярное полное, дифференциальное резервное копирование и резервное копирование журнала транзакций, выполняет резервное копирование файлов / папок, архивирует и шифрует резервные копии, сохраняет их в сети или на FTP-сервере. или в облаке (Amazon S3 и другие — мы постоянно добавляем новые), удаляет старые резервные копии и отправляет по электронной почте подтверждение об успехе или неудаче задания.
Как используется SQLBackupAndFTP?
SQLBackupAndFTP идеально подходит для любой базы данных SQL Server, MySQL, PostgreSQL, Azure SQL или Amazon RDS SQL, где резервные копии должны отправляться на FTP, SFTP, FTPS, NAS, локальную или сетевую папку, Google Drive, Dropbox, OneDrive, Box, Amazon. S3 (и любое хранилище, совместимое с S3), Azure Storage, Backblaze B2, Яндекс.Диск. Это особенно полезно для любых версий SQL Server, включая Azure SQL и Amazon RDS SQL, MySQL и MariaDB или PostgreSQL, поскольку они не имеют встроенных инструментов для резервного копирования.
Когда не следует использовать
SQLBackupAndFTP сделан простым. Хотя для большинства пользователей это огромное преимущество, некоторые специфические конфигурации не обрабатываются. Вам не следует использовать SQLBackupAndFTP, если вы хотите отслеживать производительность SQL Server и планировать резервное копирование онлайн в своем браузере для большого количества серверов — SqlBak.com может вам больше подойти.
MySQL :: Справочное руководство MySQL 8.0 :: 7.2 Методы резервного копирования базы данных
7.2 Методы резервного копирования базы данных
В этом разделе кратко описаны некоторые общие методы создания резервных копий.
Создание горячего резервного копирования с помощью MySQL Enterprise Backup
Заказчики MySQL Enterprise Edition могут использовать
MySQL Enterprise
Сделать резервную копию продукта
физические резервные копии всего
экземпляры или выбранные базы данных, таблицы или и то, и другое. Этот продукт
включает функции для
инкрементный и
сжатые резервные копии.
Резервное копирование физических файлов базы данных значительно ускоряет восстановление
чем логические методы, такие как mysqldump команда. InnoDB Таблицы копируются с использованием
механизм горячего резервирования.
(В идеале таблицы InnoDB должны представлять
существенное большинство данных.) Таблицы из другого хранилища
двигатели копируются с использованием теплого
резервный механизм. Для обзора MySQL Enterprise
Продукт резервного копирования, см. Раздел 30.2, «Обзор MySQL Enterprise Backup».
Создание резервных копий с помощью mysqldump
Программа mysqldump может создавать резервные копии.Может резервное копирование всех видов таблиц. (Видеть Раздел 7.4, «Использование mysqldump для резервного копирования».)
Для таблиц InnoDB можно выполнить
оперативное резервное копирование, которое не блокирует таблицы с помощью - одинарная транзакция опцион на mysqldump . См. Раздел 7.3.1, «Установка политики резервного копирования».
Создание резервных копий путем копирования файлов таблиц
Таблицы MyISAM могут быть скопированы путем копирования файлов таблиц.
( *.Файлы MYD , * .MYI и
связанные файлы * .sdi ). Чтобы получить последовательный
резервное копирование, остановите сервер или заблокируйте и очистите соответствующие таблицы:
ПРОМЫВКА ТАБЛИЦ tbl_list С БЛОКИРОВКОЙ СЧИТЫВАНИЯ; Вам нужна только блокировка чтения; это позволяет другим клиентам продолжить для запроса таблиц, пока вы делаете копию файлов в каталог базы данных. Смыв нужен для того, чтобы все активные страницы индекса записываются на диск перед запуском резервное копирование.См. Раздел 13.3.6, «Операторы LOCK TABLES и UNLOCK TABLES» и Раздел 13.7.8.3, «Отчет FLUSH».
Вы также можете создать двоичную резервную копию, просто скопировав таблицу
файлы, пока сервер ничего не обновляет. (Но обратите внимание
методы копирования файлов таблицы не работают, если ваша база данных
содержит таблиц InnoDB . Кроме того, даже если
сервер не обновляет данные активно, InnoDB возможно, все еще были изменены данные, кэшированные в памяти и не сброшенные в
диск.)
Для примера этого метода резервного копирования см. Экспорт и пример импорта в Раздел 13.2.5, «Оператор IMPORT TABLE».
Создание резервных копий файлов с разделителями
Чтобы создать текстовый файл, содержащий данные таблицы, вы можете использовать ВЫБРАТЬ * В АУТФАЙЛ
' . Файл создан
на хосте сервера MySQL, а не на хосте клиента. Для этого заявления
выходной файл не может уже существовать, поскольку разрешает файлы
быть перезаписанным представляет собой угрозу безопасности.Видеть
Раздел 13.2.10, «Оператор SELECT». Этот метод работает для любых данных
файл, но сохраняет только данные таблицы, но не структуру таблицы. имя_файла ' ОТ наименование таблицы
Другой способ создания файлов текстовых данных (вместе с файлами, содержащими CREATE TABLE операторов для
резервные копии таблиц) — использовать mysqldump с - вкладка опция. Видеть
Раздел 7.4.3, «Выгрузка данных в текстовом формате с разделителями с помощью mysqldump».
Чтобы перезагрузить файл данных с текстовыми разделителями, используйте ДАННЫЕ НАГРУЗКИ или mysqlimport .
Создание инкрементных резервных копий путем включения двоичного журнала
MySQL поддерживает инкрементное резервное копирование с использованием двоичного журнала. В двоичные файлы журнала предоставляют вам информацию, необходимую для реплицировать изменения в базу данных, внесенные после точка, в которой вы выполнили резервное копирование. Следовательно, чтобы позволить сервер для восстановления на определенный момент времени, двоичное ведение журнала должно быть включен на нем, что является настройкой по умолчанию для MySQL 8.0 ; см. раздел 5.4.4, «Двоичный журнал».
В настоящий момент вы хотите сделать инкрементную резервную копию (содержащую
все изменения, произошедшие с момента последнего полного или инкрементального
резервная копия), вы должны повернуть двоичный журнал, используя ЖУРНАЛ ПРОМЫВКИ . Это сделано, вам нужно
скопируйте в резервную копию все двоичные журналы, начиная с
один из моментов последнего полного или инкрементного резервного копирования на
предпоследний. Эти двоичные журналы представляют собой инкрементную резервную копию; в
время восстановления, вы применяете их, как описано в
Раздел 7.5, «Моментальное (инкрементное) восстановление». В следующий раз, когда вы сделаете
полная резервная копия, вы также должны повернуть двоичный журнал, используя ПРОМЫВКА ЖУРНАЛА или mysqldump
—flush-журналы . См. Раздел 4.5.4, «mysqldump — Программа резервного копирования базы данных».
Создание резервных копий с использованием реплик
Если у вас проблемы с производительностью сервера при создании резервного копирования, одна из стратегий, которая может помочь, — это настроить репликацию и выполнять резервное копирование на реплике, а не на источнике.Видеть Раздел 17.4.1, «Использование репликации для резервного копирования».
Если вы создаете резервную копию реплики, вы должны создать резервную копию ее соединения.
репозиторий метаданных и репозиторий метаданных приложения (см.
Раздел 17.2.4, «Репозитории ретрансляционных журналов и метаданных репликации») при резервном копировании реплик.
баз данных, независимо от выбранного вами метода резервного копирования. Этот
информация всегда нужна для возобновления репликации после того, как вы
восстановить данные реплики. Если ваша реплика реплицируется ЗАГРУЗИТЬ ДАННЫЕ , вы должны
также сделайте резервную копию любых файлов SQL_LOAD- * , которые существуют
в каталоге, который реплика использует для этой цели.В
реплике нужны эти файлы для возобновления репликации любого прерванного ЗАГРУЗИТЬ ДАННЫЕ операций. Местоположение
этого каталога — значение системной переменной replica_load_tmpdir (из MySQL
8.0.26) или slave_load_tmpdir (до MySQL 8.0.26). Если сервер не был запущен с этим
набор переменных, расположение каталога является значением tmpdir системная переменная.
Восстановление поврежденных таблиц
Если вам нужно восстановить MyISAM таблицы, которые имеют
становятся коррумпированными, попробуйте восстановить их, используя СТОЛ ДЛЯ РЕМОНТА или myisamchk
-r первый.Это должно работать в 99,9% всех случаев. Если myisamchk выходит из строя, см.
Раздел 7.6, «Обслуживание таблиц MyISAM и восстановление после сбоя».
Создание резервных копий с помощью снимка файловой системы
Если вы используете файловую систему Veritas, вы можете сделать резервную копию, например это:
Из клиентской программы выполните
FLUSH ТАБЛИЦЫ С БЛОКИРОВКОЙ СЧИТЫВАНИЯ.Из другой оболочки выполните
mount vxfs снимок.Из первого клиента выполните
РАЗБЛОКИРОВАТЬ ТАБЛИЦЫ.Скопируйте файлы из снимка.
Размонтируйте снимок.
Подобные возможности создания снимков могут быть доступны в другом файле. системы, такие как LVM или ZFS.
Резервное копирование базы данных— Академия резервного копирования Sql Server
Каждый, кто работает с базами данных SQL Server первым или последним, сталкивается с необходимостью защиты своей информации.Это подразумевает создание резервных копий базы данных. Так что же такое резервная копия базы данных? Резервное копирование базы данных — это процесс сохранения вашей базы данных в ее текущем состоянии. Это позволяет сделать копию вашей базы данных на случай, если вы внесли ненужные изменения и хотите откатиться или ваша основная база данных повреждена.
Типы резервных копий SQL Server
Существует три основных типа резервного копирования:
- Полная резервная копия базы данных создает резервную копию, содержащую все файлы данных и активную часть журнала транзакций.
- Дифференциальное резервное копирование базы данных создает резервную копию, содержащую все изменения, внесенные в базу данных с момента последней полной резервной копии и активную часть журнала транзакций.
- Резервная копия журнала транзакций содержит все записи журнала, для которых не было выполнено резервное копирование, вплоть до последней записи журнала, существующей на момент завершения резервного копирования. Следует признать, что резервное копирование журнала транзакций может быть выполнено только в том случае, если вы используете модель восстановления с полным или неполным протоколированием.
Как часто следует выполнять резервное копирование баз данных?
Имейте в виду, что для поддержания ваших баз данных в целости и сохранности вы должны регулярно делать резервные копии.Здесь возникает вопрос: «Как часто мне следует делать резервную копию своих баз данных?» Ответ: это зависит от размера вашей базы данных, от того, как часто вы вносите изменения в свою базу данных, насколько важны ваши данные и т. Д. Например, вы можете делать полную резервную копию каждые 24 часа, дифференциальную резервную копию каждые 6 часов и резервное копирование. ваш журнал транзакций каждый час.
Есть много способов сделать резервную копию базы данных. Однако в этой статье мы рассмотрим только три из них.
Как сделать резервную копию SQL Server с помощью команд T-SQL
Для создания полной резервной копии выполните команду «BACKUP DATABASE»:
РЕЗЕРВНАЯ БАЗА ДАННЫХ your_database TO DISK = 'full.бак '
Для дифференциальной резервной копии необходимо добавить предложение «WITH DIFFERENTIAL»:
РЕЗЕРВНАЯ БАЗА ДАННЫХ your_database TO DISK = 'diff.bak' С ДИФФЕРЕНЦИАЛОМ
Для резервного копирования журнала транзакций используйте команду «BACKUP LOG»:
РЕЗЕРВНЫЙ ЖУРНАЛ your_database TO DISK = 'log.bak'
Как сделать резервную копию SQL Server с помощью SSMS
Если на вашем компьютере установлена SQL Management Studio, вы можете создать резервную копию своей базы данных, выполнив всего несколько простых шагов, как описано в видео ниже:
Как сделать резервную копию SQL Server с помощью SqlBackupAndFtp
Возможно, самый простой способ регулярно создавать резервные копии базы данных — использовать утилиту SqlBackupAndFtp.В этом коротком видео подробно объясняется, как это сделать:
Создание резервных копий — Документация по продукту Acquia
Приложение Cloud Platform состоит из трех основных частей: кода, баз данных и файлы. На Cloud Platform доступно несколько типов резервных копий:
Автоматическое резервное копирование баз данных
Всегда доступны ежедневные резервные копии за последние три дня. Ты можешь делать больше резервных копий в любое время, например, для критических этапов разработка.Вам также следует периодически проверять, завершено ли резервное копирование. как и ожидалось, и проверьте, можете ли вы восстановить веб-сайты из резервной копии.
Cloud Platform создает ежедневные резервные копии всех баз данных во всех средах и хранит их три дня. Эти резервные копии перечислены как Daily на Базы данных страница в пользовательском интерфейсе облачной платформы. Эти ежедневные резервные копии являются обязательными и не могут быть отключены.
Резервное копирование базы данных по запросу
Вы можете создавать резервные копии любой базы данных по запросу в любое время в Интерфейс Cloud Platform на любой из следующих страниц:
Эти резервные копии перечислены как Пользовательские резервные копии на странице Базы данных в Пользовательский интерфейс облачной платформы.Облачная платформа хранит ваши резервные копии по запросу пока вы их не удалите. Ваши резервные копии учитываются в соответствии с ограничением места для хранения связанный с вашей подпиской.
Создание резервной копии базы данных на странице «Среды» приложения
В пользовательском интерфейсе Cloud Platform выберите свое приложение.
На карте среды, для которой требуется создать резервную копию, выберите Резервное копирование баз данных значок.
В списке баз данных выполните одно из следующих действий:
- Чтобы создать резервную копию одной или нескольких конкретных баз данных, установите флажки для баз данных.
- Чтобы создать резервную копию всех баз данных, выберите Все .
Выбрать Продолжить .
В диалоговом окне подтверждения выберите Резервное копирование .
Создание резервной копии базы данных на странице обзора среды
В пользовательском интерфейсе Cloud Platform выберите свое приложение и среда.
На карточке Базы данных выберите Резервное копирование .
В списке баз данных выполните одно из следующих действий:
- Чтобы создать резервную копию одной или нескольких конкретных баз данных, установите флажки для баз данных.
- Чтобы создать резервную копию всех баз данных, выберите Все .
Выбрать Продолжить .
В диалоговом окне подтверждения выберите Резервное копирование .
Создание резервной копии базы данных на странице Базы данных
В пользовательском интерфейсе Cloud Platform выберите свое приложение и среда.
На левой навигационной панели выберите Базы данных .
Найдите базу данных, резервную копию которой вы хотите создать, и выберите соответствующий Резервное копирование вариант.
В диалоговом окне Резервное копирование баз данных выберите Резервное копирование .
Процесс резервного копирования может занять несколько минут.
Для просмотра созданной резервной копии выберите Просмотреть все резервные копии .
Загрузка, восстановление или удаление резервных копий
На странице Базы данных в интерфейсе Cloud Platform вы можете скачать, восстановить или удалить (удалить) резервные копии.
На странице Базы данных найдите базу данных, которой вы хотите управлять.
Примечание
Для получения информации об определении имени базы данных для размещенного веб-сайта by Site Factory, см. Метаданные веб-сайта.
Выберите Просмотреть все резервные копии для базы данных.
Резервное копирование по запросу обозначается Пользователь , а автоматическое резервное копирование обозначается Ежедневно .
- Чтобы загрузить резервную копию базы данных, выберите Загрузить .
- Чтобы восстановить резервную копию базы данных, выберите Восстановить .
- Чтобы удалить резервную копию базы данных, выберите Удалить .
Примечание
Если вы восстанавливаете базу данных, убедитесь, что восстановление базы данных location имеет размер больше, чем размер базы данных.
Скачивание резервных копий из командной строки
Вы также можете загрузить любую резервную копию своей базы данных, используя команду линия. Используя функциональность Acquia CLI, вы можете найти резервную копию, которую ищете для с:
acli api: среды: список-резервных баз данных
Вы можете скачать его с помощью:
acli api: среды: загрузка-резервная-база данных
Для получения дополнительной информации см. Команды интерфейса командной строки Acquia.
Резервные копии кода
Ваш код хранится в репозитории контроля версий, управляемом Acquia. Каждый когда вы используете пользовательский интерфейс Cloud Platform, чтобы перетащить код из среда, в которой работает мастер или ветка, новый тег будет создан в система контроля версий. Вы можете вернуться к более раннему тегу в любое время в любом из ваше окружение.
Резервные копии файлов
Ваши загруженные файлы хранятся отдельно от вашей кодовой базы и базы данных Drupal,
используя символическую ссылку на каталог / files вашего приложения.Git
система контроля версий может управлять текстовыми файлами, заполненными кодом, но хуже
подходит для управления большими коллекциями загруженных пользователями объектов, таких как изображения,
видео или прикрепленные файлы.
Cloud Platform делает внутренние снимки аварийного восстановления ваших файлов, но они недоступны для подписчиков в обычных целях резервного копирования. Если ты хочешь для резервного копирования загруженных файлов вы можете сделать это вручную с помощью команды line или создайте задачу cron для регулярного резервного копирования.
Для получения дополнительной информации см. Работа с файлами и Резервное копирование. ваша файловая система Drupal.
Пользовательские полные резервные копии сайта
Вы можете создать резервную копию всего приложения в среде из командной строки,
используя Drush. Команда drush archive-dump создает полный архивный файл.
вашего приложения.
Важно
Выполнение этой команды на большом веб-сайте (с большим количеством файлов, большие базы данных или тома с небольшой областью файлов) могут привести к полному disk, что приведет к зависанию скрипта и отключению веб-сайта.
Команда drush archive-dump несовместима с Drush 9.
Например, для резервного копирования среды Prod приложения с именем пример1 :
drush @ example1.prod архив-дамп
По умолчанию файл резервной копии сохраняется в папке drush-backups . Использовать --destination , чтобы указать полный путь и имя файла, в котором
архив надо хранить.