ГлавнаяРазноеРезервное копирование mssql 2018

Автоматизируем бэкап баз данных MSSQL Express. Резервное копирование mssql 2018


Автоматизируем бэкап баз данных MSSQL Express

Дата: 26.05.2015 Автор Admin

В данной статье мы рассмотрим как настроить автоматическое резервное копирование баз данных MSSQL расположенных на бесплатном MSSQL Express.

Для автоматизации резервного копирования напишем следующий sql скрипт:

declare @path varchar(max)=N'C:\Backup\BASE_backup_'+convert(varchar(max),getdate(),102) BACKUP DATABASE [BASE_NAME] TO DISK = @path WITH COPY_ONLY, NOFORMAT, NOINIT, NAME = N'BASE_NAME-Полная База данных Резервное копирование', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO

declare @path varchar(max)=N'C:\Backup\BASE_backup_'+convert(varchar(max),getdate(),102)

BACKUP DATABASE [BASE_NAME] TO  DISK = @path  WITH  COPY_ONLY, NOFORMAT, NOINIT,  NAME = N'BASE_NAME-Полная База данных Резервное копирование', SKIP, NOREWIND, NOUNLOAD,   STATS = 10

GO

Кодировка скрипта должны быть — UCS-2 Little Endian

Рассмотрим параметры скрипта:

Путь куда сохранять резервные копии указывается тут — C:\Backup\

Имя резервной копии будет начинаться с BASE_backup_ и заканчиваться датой резервного копирования.

Имя базы, которую мы будем сохранять задается тут:

BACKUP DATABASE [BASE_NAME]

BACKUP DATABASE [BASE_NAME]

И тут:

Далее открываем планировщик задач Windows и создаем новую задачу.

В поле «действие» выбираем «Запуск программы»

Путь к программе — «C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.EXE»

Аргументы — -S \sqlexpress  -i «C:\Backup_ScriptDir\backup.sql»

Рассмотрим параметры:

-S \sqlexpress путь к инстансу MSSQL, в данном примере инстанс sqlexpress

Если у вас используется локальный инстанс укажите просто \

-i «C:\Backup_ScriptDir\backup.sql» путь к созданному SQL скрипту.

Готово! Теперь резервное копирование MSSQL баз автоматизированно!

Похожие статьи

ittraveler.org

Устройства резервного копирования (SQL Server)

 

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

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

набор носителейУпорядоченный набор носителей резервного копирования, ленточных накопителей или дисковых файлов, которые используют определенный тип и количество устройств резервного копирования. Сведения о наборах носителей см. в разделе Наборы носителей, семейства носителей и резервные наборы данных (SQL Server).

физическое устройство резервного копированияЛенточный накопитель или дисковый файл, предоставленный операционной системой. В резервном копировании может участвовать от 1 до 64 устройств. Если для резервного копирования требуется несколько устройств, все устройства должны быть одного типа (диск или ленточный накопитель).

Кроме диска или магнитной ленты, резервное копирование SQL Server можно также выполнять в службу хранилища BLOB-объектов Windows Azure.

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

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

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

ВАЖНО! Резервные копии, базы данных и журналы рекомендуется хранить на разных дисках. Это является необходимым, чтобы можно было гарантировать возможность доступа к резервным копиям при сбое диска с базой данных или журналами.

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

Базовый синтаксис инструкции BACKUP для указания файла резервного копирования с помощью его физического имени:

BACKUP DATABASE database_name

TO DISK = { 'physical_backup_device_name' | @physical_backup_device_name_var }

Например:

BACKUP DATABASE AdventureWorks2012 TO DISK = 'Z:\SQLServerBackups\AdventureWorks2012.bak'; GO

Базовый синтаксис для указания физического жесткого диска в инструкции RESTORE :

RESTORE { DATABASE | LOG } database_name

FROM DISK = { 'physical_backup_device_name' | @physical_backup_device_name_var }

Например:

RESTORE DATABASE AdventureWorks2012 FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2012.bak';

При указании файла резервного копирования следует ввести полный путь и имя файла. Если введено только имя файла или относительный путь для резервного копирования на диск, то файл резервной копии будет помещен в определенный по умолчанию каталог для резервных копий. Резервным каталогом по умолчанию является C:\Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\Backup, где n — номер экземпляра сервера. Поэтому для экземпляра сервера по умолчанию каталогом, использующимся по умолчанию для резервного копирования, является C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Backup.

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

BACKUP DATABASE AdventureWorks2012 TO DISK = ’AdventureWorks2012.bak’; GO

ПРИМЕЧАНИЕ. Расположение по умолчанию хранится в разделе реестра BackupDirectory по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.n\MSSQLServer.

Резервное копирование в файл, расположенный в общей сетевой папке

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

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

  • Если файл Sqlservr.exe запускается как служба, то SQL Server выполняется в отдельном сеансе, который не связан с пользовательским сеансом. Сеанс службы может иметь собственные подключенные сетевые диски, но, как правило, они отсутствуют.

  • Можно подключиться, используя учетную запись сетевой службы, если вместо пользователя домена указать учетную запись компьютера. Чтобы разрешить выполнение резервного копирования с определенных компьютеров на общий диск, нужно предоставить доступ к учетным записям компьютеров. Пока процесс Sqlservr.exe имеет доступ на запись резервных копий, было бы неправильно предоставлять доступ пользователю, посылающему инструкцию BACKUP.

    ВАЖНО! Резервное копирование данных через сеть может быть причиной сетевых ошибок. Поэтому при использовании удаленного диска рекомендуется проверять операцию резервного копирования после ее завершения. Дополнительные сведения см. в разделе RESTORE VERIFYONLY (Transact-SQL).

Чтобы указать сетевой ресурс в команде резервного копирования или восстановления, для файла, расположенного на устройстве резервного копирования, следует использовать полностью заданное имя в формате UNC. Имя в формате UNC имеет форму \\Имя_системы\Имяобщегоресурса\Путь\Имя_файла.

Например:

BACKUP DATABASE AdventureWorks2012 TO DISK = '\\BackupSystem\BackupDisk1\AW_backups\AdventureWorksData.Bak'; GO

ПРИМЕЧАНИЕ. Поддержка ленточных устройств резервного копирования будет удалена в одной из будущих версий SQL Server. Избегайте использования этого компонента в новых разработках и запланируйте изменение существующих приложений, в которых он применяется.

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

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

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

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

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

Базовый синтаксис инструкции BACKUP для указания ленты резервного копирования с помощью физического имени накопителя на магнитной ленте:

BACKUP { DATABASE | LOG } database_name

TO TAPE = { 'physical_backup_device_name' | @physical_backup_device_name_var }

Например:

BACKUP LOG AdventureWorks2012 TO TAPE = '\\.\tape0'; GO

Базовый синтаксис для указания физического ленточного устройства в инструкции RESTORE :

RESTORE { DATABASE | LOG } database_name

FROM TAPE = { 'physical_backup_device_name' | @physical_backup_device_name_var }

Параметры BACKUP и RESTORE для ленточных устройств (Transact-SQL)

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

  • { NOUNLOAD | UNLOAD }

    Предоставляет управление автоматической выгрузкой ленты из накопителя на магнитной ленте после завершения операций резервного копирования или восстановления. Параметр UNLOAD/NOUNLOAD является настройкой сеанса, он сохраняется в течение работы сеанса или пока не будет сброшен при указании другого значения.

  • { REWIND | NOREWIND }

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

ПРИМЕЧАНИЕ. Дополнительные сведения о синтаксисе BACKUP и его аргументах см. в разделе BACKUP (Transact-SQL). Дополнительные сведения о синтаксисе RESTORE и его аргументах см. в разделах RESTORE (Transact-SQL) и Аргументы RESTORE (Transact-SQL) соответственно.

Управление открытыми магнитными лентами

Для просмотра списка открытых ленточных устройств и состояния запросов на подключение запросите динамическое представление управления sys.dm_io_backup_tapes. Данное представление показывает все открытые ленты. Сюда относятся все используемые ленты, которые временно простаивают в ожидании следующей операции BACKUP или RESTORE.

Если лента была случайно оставлена открытой, то самый быстрый способ освободить ее — использовать следующую команду: RESTORE REWINDONLY FROM TAPE =backup_device_name. Дополнительные сведения см. в разделе RESTORE REWINDONLY (Transact-SQL).

Резервные копии SQL Server могут быть записаны в службу хранилища BLOB-объектов Windows Azure. Дополнительные сведения о том, как использовать службу хранилища BLOB-объектов Microsoft Azure для резервного копирования, см. в разделе Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure.

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

Определение логического устройства резервного копирования включает в себя назначение логического имени физическому устройству. Например, логическое устройство AdventureWorksBackups можно определить таким образом, чтобы оно указывало на файл Z:\SQLServerBackups\AdventureWorks2012.bak или ленточный накопитель \\.\tape0. Затем в командах резервного копирования и восстановления в качестве устройства резервного копирования можно указывать AdventureWorksBackups вместо DISK = "Z:\SQLServerBackups\AdventureWorks2012.bak" или \\.\tape0.

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

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

BACKUP DATABASE AdventureWorks2012 TO AdventureWorksBackups; GO

ПРИМЕЧАНИЕ. В данной инструкции BACKUP или RESTORE имя логического устройства резервного копирования и имя соответствующего физического устройства резервного копирования являются взаимозаменяемыми.

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

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

  1. Удаление исходного логического устройства резервного копирования.

  2. Определение нового логического устройства резервного копирования, имя которого совпадает с именем исходного логического устройства, но которое сопоставлено с другим физическим устройством резервного копирования. Логические устройства резервного копирования особенно полезны для указания ленточных устройств резервного копирования.

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

ПРИМЕЧАНИЕ. Зеркальные наборы носителей резервной копии поддерживаются только в выпуске SQL Server 2005 Enterprise Edition и более поздних версиях.

Для архивации дисковых резервных копий рекомендуется пользоваться программой архивации файловой системы, а также хранить архивы вне вычислительной системы. Использование жесткого диска дает возможность использовать сеть для записи заархивированных резервных копий на диск, расположенный вне вычислительной системы. Хранилище BLOB-объектов Windows Azure можно использовать в качестве средства архивирования. Можно либо загружать дисковые резервные копии, либо непосредственно записать копии в службу хранилища BLOB-объектов Windows Azure.

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

Указание логического устройства резервного копирования (среда SQL Server Management Studio)

Указание ленточного устройства (среда SQL Server Management Studio)

Определение логического устройства резервного копирования

Использование логического устройства резервного копирования

Просмотр сведений об устройствах резервного копирования

technet.microsoft.com

Резервное копирование SQL Server на URL-адрес — рекомендации и устранение неполадок

 

ОБЛАСТЬ ПРИМЕНЕНИЯ ЭТОЙ СТАТЬИ: SQL Server (начиная с 2016) База данных SQL Azure Хранилище данных SQL Azure Parallel Data Warehouse

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

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

В следующем списке перечислены общие рекомендации по управлению резервным копированием.

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

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

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

  • Сбой во время резервного копирования может привести к созданию неработоспособного файла резервной копии. Рекомендуется периодически проводить поиск неудачных резервных копий и удалять файлы больших двоичных объектов. Дополнительные сведения см. в разделе Deleting Backup Blob Files with Active Leases.

  • Использование параметра WITH COMPRESSION во время резервного копирования может уменьшить стоимость хранения и транзакционные издержки хранения. Также может сократиться время, необходимое для выполнения резервного копирования.

  • Операция резервного копирования SQL Server выполняется в несколько потоков, чтобы оптимизировать передачу данных к службам хранилищ больших двоичных объектов Windows Azure. Однако производительность зависит от различных факторов, в том числе от пропускной способности ISV и размера базы данных. Если планируется создавать резервные копии больших баз данных или файловых групп в локальной базе данных SQL Server, вначале рекомендуется проверить пропускную способность. В соглашении об уровне обслуживания для службы хранилища Azure определены максимальные значения времени обработки для больших двоичных объектов, которыми можно руководствоваться.

  • При создании резервных копий больших файлов очень важно использовать параметр WITH COMPRESSION в соответствии с рекомендациями, приведенными в разделе Управление резервным копированием .

Ниже приведено несколько простых способов устранения ошибок при создании резервной копии или восстановлении из службы хранилища больших двоичных объектов Windows Azure.

Чтобы избежать ошибок из-за неподдерживаемых параметров или ограничений, просмотрите список ограничений и информацию о поддержке для команд BACKUP и RESTORE в статье Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure.

Ошибки проверки подлинности:

  • WITH CREDENTIAL — это новый параметр, который необходимо использовать при создании резервных копий или восстановлении с помощью службы хранилища больших двоичных объектов Windows Azure. Ниже приводятся возможные ошибки, связанные с учетными данными.

    Учетные данные, заданные в команде BACKUP или RESTORE , не существуют. Чтобы избежать этой проблемы, можно включить инструкцию T-SQL для создания учетных данных, если она отсутствует в инструкции резервного копирования. Ниже приводится пример, который можно использовать.

    IF NOT EXISTS (SELECT * FROM sys.credentials WHERE credential_identity = 'mycredential') CREATE CREDENTIAL <credential name> WITH IDENTITY = 'mystorageaccount' ,SECRET = '<storage access key> ;

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

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

Ошибки и сбои резервного копирования:

  • Параллельное выполнение резервного копирования в один большой двоичный объект вызывает сбой одной из резервных копий с ошибкой Ошибка инициализации .

  • Используйте следующие журналы об ошибке, чтобы помочь при устранении неполадок в резервных ошибках:

    • Установите флаг трассировки 3051, чтобы включить ведение записей в конкретном журнале ошибок в следующем формате:

      BackupToUrl-<instname>-<dbname>-action-<PID>.log, где <action> может принимать одно из следующих значений:

      • DB

      • FILELISTONLY

      • LABELONLY

      • HEADERONLY

      • VERIFYONLY

    • Дополнительную информацию можно найти в журнале событий Windows или в журналах приложений с именем «SQLBackupToUrl».

  • При восстановлении из сжатой резервной копии может появиться следующее сообщение об ошибке:

    • Возникло SqlException 3284. Серьезность: 16, состояние: 5Метка файла сообщения на устройстве https://mystorage.blob.core.windows.net/mycontainer/TestDbBackupSetNumber2_0.bak не согласована. Перезапустите инструкцию Restore с тем же размером блока, который использовался при создании резервного набора данных. Возможно, следует указать «65536».

      Чтобы устранить эту ошибку, издайте инструкцию BACKUP повторно и укажите для нее значение BLOCKSIZE = 65536.

  • Ошибка во время архивации из-за больших двоичных объектов с активной арендой: сбой операции архивации может привести к появлению больших двоичных объектов с активными арендами.

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

    Резервное копирование на URL-адрес получило исключение из удаленной конечной точки. Сообщение об исключении: удаленный сервер возвратил ошибку: (412) в настоящее время существует аренда для большого двоичного объекта, однако для запроса не указан идентификатор аренды.

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

    Сообщение об исключении: удаленный сервер вернул ошибку: (409) конфликт…

    Если возникает такая ошибка, файлы больших двоичных объектов следует удалить. Дополнительные сведения об этом сценарии и устранении этой проблемы см. в разделе Deleting Backup Blob Files with Active Leases.

При использовании прокси-серверов для доступа к Интернету возможны следующие проблемы.

Регулирование соединений прокси-серверами.

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

  • Сбой записи в "http://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak". При архивации на URL-адрес получено исключение из удаленной конечной точки. Сообщение об исключении: не удалось прочитать данные из транспортного соединения. Соединение было закрыто.

  • Произошла неустранимая ошибка ввода-вывода в файле "http://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak". Не удалось получить данные ошибки из удаленной конечной точки.

    Сообщение 3013, уровень 16, состояние 1, строка 2

    Процесс BACKUP DATABASE завершается аварийно.

  • BackupIoRequest::ReportIoError: ошибка записи в устройство резервного копирования http://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak. Ошибка операционной системы. Процесс резервного копирования на URL-адрес получил исключение от удаленной конечной точки. Сообщение об исключении: не удалось прочитать данные из транспортного соединения. Соединение было закрыто.

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

Код состояния HTTP 502, ошибка прокси-сервера сообщения о состоянии HTTP (количество HTTP-запросов в минуту превышает установленный предел. Обратитесь к администратору сервера ISA. )

Параметры прокси-сервера по умолчанию не используются.

Иногда, если не выбраны параметры по умолчанию, это приводит к ошибкам аутентификации на прокси-сервере наподобие следующей: Произошла неустранимая ошибка ввода-вывода в файле "http://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak". При архивации на URL-адрес получено исключение из удаленной конечной точки. Сообщение об исключении: удаленный сервер вернул ошибку: (407) требуется аутентификация на прокси-сервере.

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

  1. Создайте файл конфигурации BackuptoURL.exe.config со следующим XML-кодом:

    <?xml version ="1.0"?> <configuration> <system.net> <defaultProxy enabled="true" useDefaultCredentials="true"> <proxy usesystemdefault="true" /> </defaultProxy> </system.net> </configuration>

  2. Поместите файл конфигурации в папку Binn на экземпляре SQL Server. Например, если SQL Server установлен на диске C компьютера, поместите файл конфигурации сюда: C:\Program Files\Microsoft SQL Server\MSSQL13.<имя_экземпляра>>\MSSQL\Binn.

Восстановление из резервных копий в Microsoft Azure BACKUP (Transact-SQL) RESTORE (Transact-SQL)

technet.microsoft.com

Создание полной резервной копии базы данных (SQL Server)

 

В этом разделе описывается создание полной резервной копии базы данных в SQL Server 2016 с помощью SQL Server Management Studio, Transact-SQL или PowerShell.

Сведения о резервном копировании SQL Server в службу хранилища BLOB-объектов Windows Azure см. в разделах Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure и Резервное копирование SQL Server по URL-адресу.

Ограничения

  • Инструкция BACKUP не разрешена в явных и неявных транзакциях.

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

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

Рекомендации

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

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

  • По умолчанию каждая успешная операция резервного копирования добавляет запись в журнал ошибок служб SQL Server и в журнал системных событий. Если резервное копирование выполняется часто, сообщения об успешном завершении операций накапливаются быстро, что приводит к стремительному увеличению журналов ошибок! Это может осложнить поиск других сообщений. Если работа существующих скриптов не зависит от записей журнала резервного копирования, то их можно отключить с помощью флага трассировки 3226. Дополнительные сведения см. в разделе Флаги трассировки (Transact-SQL).

Безопасность

Для резервной копии базы данных свойству TRUSTWORTHY присваивается значение OFF. Дополнительные сведения о том, как задать для параметра TRUSTWORTHY значение ON, см. в разделе Параметры ALTER DATABASE SET (Transact-SQL).

Начиная с SQL Server 2012 , параметры PASSWORD и MEDIAPASSWORD не поддерживаются при создании резервных копий. Все еще вы можете восстанавливать резервные копии, созданные с паролями.

Разрешения

Разрешения BACKUP DATABASE и BACKUP LOG назначены по умолчанию членам предопределенной роли сервера sysadmin и предопределенным ролям базы данных db_owner и db_backupoperator.

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

При создании задания резервного копирования с помощью среды SQL Server Management Studio вы можете сформировать соответствующий скрипт Transact-SQL  BACKUP, нажав кнопку Скрипт и выбрав назначение скрипта.

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

  1. После подключения к соответствующему экземпляру Microsoft Компонент SQL Server Database Engine в обозревателе объектов разверните дерево сервера, щелкнув его имя.

  2. Разверните узел Базы данных и выберите пользовательскую базу данных или разверните узел Системные базы данных и выберите системную базу данных.

  3. Щелкните правой кнопкой мыши базу данных, выберите пункт Задачи, а затем команду Создать резервную копию. Откроется диалоговое окно Резервное копирование базы данных .

Страница «Общие»

  1. В раскрывающемся списке База данных проверьте имя базы данных. При необходимости можно выбрать другую базу данных из списка.

  2. Текстовое поле Модель восстановления предназначено только для справки. Резервное копирование базы данных можно выполнять для любой модели восстановления (FULL, BULK_LOGGED или SIMPLE).

  3. В раскрывающемся списке Тип резервной копии выберите Полный.

    Обратите внимание на то, что при создании полной резервной копии базы данных можно создавать разностные резервные копии; дополнительные сведения см. в разделе Создание разностной резервной копии базы данных (SQL Server).

  4. Также можно установить флажок Архивная копия только для копирования, чтобы создать резервную копию только для копирования. Резервная копия только для копирования — это резервная копия SQL Server, которая не зависит от обычной последовательности создания традиционных резервных копий SQL Server. Дополнительные сведения см. в разделе Резервные копии только для копирования (SQL Server). Резервная копия только для копирования недоступна для типа резервной копии Разностная.

  5. Для параметра Компонент резервного копирования выберите переключатель База данных.

  6. В разделе Назначения воспользуйтесь раскрывающимся списком Создать резервную копию на для выбора назначения резервного копирования. Нажмите кнопку Добавить, чтобы добавить дополнительные назначения и/или объекты резервного копирования.

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

Страница "Параметры носителя"

  1. Для просмотра или выбора параметров носителя нажмите кнопку Параметры носителя на панели Выбор страницы .

  2. Выберите параметр Переписать носитель , указав один из следующих вариантов:

  • Создать резервную копию в существующем наборе носителей

     Важно

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

    Для этого параметра выберите вариант Добавить в существующий резервный набор данных или Перезаписать все существующие резервные наборы данных. Дополнительные сведения см. в разделе Наборы носителей, семейства носителей и резервные наборы данных (SQL Server).

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

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

  • Создать резервную копию в новом наборе носителей и удалить все существующие резервные наборы данных

    Для этого параметра введите имя в текстовом поле Имя нового набора носителей и при необходимости введите описание набора носителей в текстовое поле Описание нового набора носителей .

  1. В разделе Надежность можно также установить флажки:

  2. Раздел Журнал транзакций доступен, только если создается резервная копия журнала транзакций (это можно указать в разделе Тип резервной копии вкладки Общие).

  3. При резервном копировании на накопитель на магнитной ленте (как указано в разделе Назначение страницы Общие) в разделе Ленточный накопитель активен параметр Выгрузить ленту после резервного копирования. Щелкните этот параметр, чтобы активировать параметр Перемотать ленту перед выгрузкой .

Страница "Параметры резервного копирования"

  1. Для просмотра или выбора параметров резервного копирования нажмите кнопку Параметры резервного копирования на панели Выбор страницы .

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

  3. При необходимости можно ввести описание резервного набора данных в текстовом поле Описание .

  4. Укажите, когда закончится срок действия резервного набора данных и когда этот набор может быть перезаписан без явного пропуска проверки на истечение срока.

    • Чтобы задать срок действия резервного набора данных, выберите пункт После (параметр по умолчанию) и введите срок действия набора в днях с момента его создания. Это значение может быть задано в диапазоне от 0 до 99 999 дней. Значение 0 означает, что срок действия резервного набора данных не ограничен.

      Значение по умолчанию задается в параметре Срок хранения носителей резервных копий по умолчанию (дней): диалогового окна Свойства сервера (страница "Параметры базы данных"). Чтобы получить доступ к этому параметру, щелкните правой кнопкой мыши имя сервера в обозревателе объектов и выберите пункт "Свойства", а затем выберите страницу Настройки базы данных.

    • Чтобы указать дату истечения срока действия резервного набора данных, выберите пункт Наи введите дату истечения срока действия резервного набора данных.

      Дополнительные сведения о дате истечения срока действия резервных копий см. в разделе BACKUP (Transact-SQL).

  5. В разделе Сжатие воспользуйтесь раскрывающимся списком Сжимать резервные копии, чтобы выбрать нужный уровень сжатия. SQL Server 2008 Enterprise и более поздние версии поддерживают сжатие резервных копий. По умолчанию сжатие резервных копий зависит от значения параметра конфигурации сервера backup-compression default. Однако независимо от текущего значения по умолчанию на уровне сервера можно сжать резервные копии, установив параметр Сжимать резервные копии, или отказаться от сжатия резервных копий, установив параметр Не сжимать резервные копии.

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

  6. В разделе Шифрование установите флажок Зашифровать резервную копию, чтобы определить, следует ли использовать шифрование для резервной копии. Используйте раскрывающийся список Алгоритм для выбора алгоритма шифрования. Используйте раскрывающийся список Сертификат или асимметричный ключ, чтобы выбрать существующий сертификат или асимметричный ключ. Шифрование поддерживается в SQL Server 2014 и более поздних версиях. Дополнительные сведения об этом параметре шифрования см. в разделе Резервное копирование базы данных (страница "Параметры резервного копирования").

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

Примеры

A. Полное резервное копирование на диск в расположение по умолчанию

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

  1. В обозревателе объектов подключитесь к экземпляру компонента SQL Server Database Engine и разверните его.

  2. Разверните узел Базы данных, щелкните правой кнопкой Sales, укажите на пункт Задачии выберите Создать резервную копию...

  3. Нажмите кнопку ОК.

Б. Полное резервное копирование на диск в нестандартное расположение

В этом примере база данных Sales будет заархивирована на диск в папку E:\MSSQL\BAK. Ранее резервные копии Sales уже создавались.

  1. В обозревателе объектов подключитесь к экземпляру компонента SQL Server Database Engine и разверните его.

  2. Разверните узел Базы данных, щелкните правой кнопкой Sales, укажите на пункт Задачии выберите Создать резервную копию...

  3. На странице Общие в разделе Назначение выберите Диск в раскрывающемся списке Создать резервную копию на:.

  4. Щелкайте элемент Удалить, пока не будут удалены все существующие файлы резервных копий.

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

  6. Введите E:\MSSQL\BAK\Sales_20160801.bak в текстовом поле имя файла.

  7. Нажмите кнопку ОК.

  8. Нажмите кнопку ОК.

В. Создание зашифрованной резервной копии

В этом примере база данных Sales будет заархивирована с шифрованием в папку резервных копий по умолчанию. Главный ключ базы данных уже создан. Уже был создан сертификат с именем MyCertificate. Пример создания главного ключа базы данных и сертификата на языке T-SQL можно просмотреть на разделе Создание зашифрованной резервной копии.

  1. В обозревателе объектов подключитесь к экземпляру компонента SQL Server Database Engine и разверните его.

  2. Разверните узел Базы данных, щелкните правой кнопкой Sales, укажите на пункт Задачии выберите Создать резервную копию...

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

  4. На странице Параметры резервного копирования в разделе Шифрование установите флажок Зашифровать резервную копию.

  5. В раскрывающемся списке Алгоритм выберите AES 256.

  6. В раскрывающемся списке Сертификат или асимметричный ключ выберите MyCertificate.

  7. Нажмите кнопку ОК.

Г. Резервное копирование в службу хранилища больших двоичных объектов Microsoft Azure
Общие шаги

В следующих трех примера выполняется полное резервное копирование базы данных Sales в службу хранилища больших двоичных объектов Microsoft Azure. Имя учетной записи хранилища — mystorageaccount. Контейнер называется myfirstcontainer. Для краткости первые четыре шага перечислены здесь однократно, а все примеры начинаются с шага 5.

  1. В обозревателе объектов подключитесь к экземпляру компонента SQL Server Database Engine и разверните его.

  2. Разверните узел Базы данных, щелкните правой кнопкой Sales, укажите на пункт Задачии выберите Создать резервную копию...

  3. На странице Общие в разделе Назначение выберите URL-адрес в раскрывающемся списке Создать резервную копию на:.

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

    Г1. Чередующееся резервное копирование на URL-адрес и в учетные данные SQL Server уже существует.Хранимая политика доступа была создана с правами на чтение, запись и составление списков. Учетные данные SQL Server, https://mystorageaccount.blob.core.windows.net/myfirstcontainer, были созданы с использованием подписанного URL-адреса, который связан с хранимой политикой доступа.

    1. Выберите https://mystorageaccount.blob.core.windows.net/myfirstcontainer из текстового поля Контейнер хранилища Azure:

    2. В текстовом поле Файл резервной копии: введите Sales_stripe1of2_20160601.bak.

    3. Нажмите кнопку ОК.

    4. Повторите шаги 4 и 5.

    5. В текстовом поле Файл резервной копии: введите Sales_stripe2of2_20160601.bak.

    6. Нажмите кнопку ОК.

    7. Нажмите кнопку ОК.

    Г2. Подписанный URL-адрес существует, а учетные данные SQL Server — нет.

    1. Введите https://mystorageaccount.blob.core.windows.net/myfirstcontainer в текстовом поле Контейнер хранилища Azure:

    2. Введите подписанный URL-адрес в текстовом поле Политика подписанных URL-адресов:.

    3. Нажмите кнопку ОК.

    4. Нажмите кнопку ОК.

    Г3. Подписанный URL-адрес не существует.

    1. Щелкните Создать контейнер, чтобы открыть диалоговое окно Соединение с подпиской Microsoft.

    2. Выполните все действия в диалоговом окне Соединение с подпиской Microsoft и нажмите кнопку ОК, чтобы вернуться в диалоговое окно Выбор места назначения резервной копии. См. дополнительные сведения в разделе Соединение с подпиской Microsoft Azure.

    3. Нажмите кнопку ОК в диалоговом окне Выбор места назначения резервной копии.

    4. Нажмите кнопку ОК.

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

  1. Выполните инструкцию BACKUP DATABASE для создания полной резервной копии базы данных, указав следующее:

    • имя базы данных для создания резервной копии;

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

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

    BACKUP DATABASE database

    TO backup_device [ ,...n ]

    [ WITH with_options [ ,...o ] ] ;

    ПараметрОписание
    База данныхБаза данных для резервного копирования.
    backup_device [ ,...n ]Указывает список от 1 до 64 устройств резервного копирования, используемых для создания резервной копии. Можно указать как физическое устройство резервного копирования, так и соответствующее логическое устройство, если оно уже определено. Для указания физического устройства резервного копирования используйте параметр DISK или TAPE.

    { DISK | TAPE } =имяфизическогоустройства_резервного _копирования

    Дополнительные сведения см. в разделе Устройства резервного копирования (SQL Server).

    WITH with_options [ ,...o ]При необходимости можно указать один или несколько дополнительных параметров, o. Сведения о некоторых основных параметрах см. в пункте 2.

  2. При необходимости укажите один или несколько параметров WITH. Здесь описываются некоторые основные параметры WITH. Сведения обо всех параметрах WITH см. в разделе BACKUP (Transact-SQL).

    • Основные параметры WITH резервного набора данных:

      { COMPRESSION | NO_COMPRESSION }Только в версии SQL Server 2008 Enterprise и выше указано, выполняется ли команда backup compression для этой резервной копии, переопределяя значение по умолчанию на уровне сервера.

      ШИФРОВАНИЕ (АЛГОРИТМ, СЕРТИФИКАТ СЕРВЕРА |АСИММЕТРИЧНЫЙ КЛЮЧ)Только для SQL Server 2014 и выше укажите используемый алгоритм шифрования, а также сертификат или асимметричный ключ для шифрования.

      DESCRIPTION = { 'text' | @text_variable }Задает произвольное текстовое описание резервного набора данных. В этой строке может содержаться до 255 символов.

      NAME = { backup_set_name | @backup_set_name_var }Указывает имя резервного набора данных. Длина имени не может превышать 128 символов. Если параметр NAME не указан, то имя является пустым.

    • Основные параметры WITH резервного набора данных:

      По умолчанию команда BACKUP добавляет резервную копию в существующий набор носителей, сохраняя существующие резервные наборы данных. Чтобы явно указать это, используйте параметр NOINIT. Сведения о присоединении к существующим резервным наборам данных см. в разделе Наборы носителей, семейства носителей и резервные наборы данных (SQL Server).

      Чтобы отформатировать носитель резервной копии используется параметр FORMAT:

      FORMAT [ , MEDIANAME= { media_name | @media_name_variable } ] [ , MEDIADESCRIPTION = { text | @text_variable } ]Используйте предложение FORMAT при первом использовании носителя или при необходимости перезаписать существующие данные. При необходимости назначьте новому носителю имя и описание.

       Важно

      Будьте предельно осторожны, используя предложение FORMAT инструкции BACKUP, так как оно удаляет все резервные копии, сохраненные ранее на носителе резервных копий.

Примеры (Transact-SQL)

А. Резервное копирование на дисковое устройство

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

USE AdventureWorks2012; GO BACKUP DATABASE AdventureWorks2012 TO DISK = 'Z:\SQLServerBackups\AdventureWorks2012.Bak' WITH FORMAT, MEDIANAME = 'Z_SQLServerBackups', NAME = 'Full Backup of AdventureWorks2012'; GO
Б. Резервное копирование на ленточное устройство

В следующем примере создается полная резервная копия базы данных AdventureWorks2012 на ленте в дополнение к предыдущим резервными копиям.

USE AdventureWorks2012; GO BACKUP DATABASE AdventureWorks2012 TO TAPE = '\\.\Tape0' WITH NOINIT, NAME = 'Full Backup of AdventureWorks2012'; GO
В. Резервное копирование на логическое ленточное устройство

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

USE master; GO EXEC sp_addumpdevice 'tape', 'AdventureWorks2012_Bak_Tape', '\\.\tape0'; USE AdventureWorks2012; GO BACKUP DATABASE AdventureWorks2012 TO AdventureWorks2012_Bak_Tape WITH FORMAT, MEDIANAME = 'AdventureWorks2012_Bak_Tape', MEDIADESCRIPTION = '\\.\tape0', NAME = 'Full Backup of AdventureWorks2012'; GO

Используйте командлет Backup-SqlDatabase. Чтобы явно указать, что это полная резервная копия базы данных, задайте параметр -BackupAction со значением по умолчанию Database. Данный параметр является необязательным для полных резервных копий баз данных.

Примеры

A. Полная локальная резервная копия

В следующем примере создается полная резервная копия базы данных MyDB в заданном по умолчанию расположении резервного копирования на экземпляре сервера Computer\Instance. Дополнительно в этом примере указывается параметр -BackupAction Database.

Backup-SqlDatabase -ServerInstance Computer\Instance -Database MyDB -BackupAction Database
Б. Полная резервная копия в Microsoft Azure

В следующем примере создается полная резервная копия базы данных Sales в экземпляре MyServer службы хранилища больших двоичных объектов Microsoft Azure. Хранимая политика доступа была создана с правами на чтение, запись и составление списков. Учетные данные SQL Server, https://mystorageaccount.blob.core.windows.net/myfirstcontainer, были созданы с использованием подписанного URL-адреса, который связан с хранимой политикой доступа. Команда PowerShell использует параметр BackupFile для указания расположения (URL-адреса) и имени файла резервной копии.

import-module sqlps; $container = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer'; $FileName = 'Sales.bak'; $database = 'Sales'; $BackupFile = $container + '/' + $FileName ; Backup-SqlDatabase -ServerInstance "MyServer" –Database $database -BackupFile $BackupFile;

Настройка и использование поставщика SQL Server PowerShell

Устранение неполадок операций резервного копирования и восстановления SQL Server Общие сведения о резервном копировании (SQL Server) Резервные копии журналов транзакций (SQL Server) Наборы носителей, семейства носителей и резервные наборы данных (SQL Server) sp_addumpdevice (Transact-SQL) BACKUP (Transact-SQL) Резервное копирование базы данных (страница "Общие") Резервное копирование базы данных (страница "Параметры резервного копирования") Разностные резервные копии (SQL Server) Полные резервные копии баз данных (SQL Server)

technet.microsoft.com

Резервное копирование и SQL | Новости N

22:08, 03.04.2018

Резервным копированием можно назвать процесс создания и хранения копий данных на стороннем носителе. Любой носитель с копией информации и ежедневной обработкой данных можно назвать рабочей копией.Резервное копирование данных — это процесс архивирования копий файлов, которые сохраняются в случае потери или повреждения компьютера. Пользователь делает «Бэкап» или восстанавливает информацию, используя специальные программы указанные в подробной статье https://www.backup-solutions.ru/rezervnoe-kopirovanie-i-vosstanovlenie-microsoft-sql-server/.

«Бэкап» означает — «запас», то есть «резервная копия» или «дубликат». Бэкап данных создаётся на внешнем носителе (жёсткий диск, CD/DVD-диск, флешка и т.д.) Регулярное архивирование данных проводится перед глобальными изменениями на жёстком диске или операциями, которые могут нанести вред структуре жёсткого диска. Новичкам перед установкой операционной системы Виндовс, нужно делать резервное копирование данных.

«Бекап» данных можно сделать на физических носителях или воспользоваться «облаком». Используя облачные хранилища, можно закачивать большие объёмы данных и хранить информацию долгое время.SQL — это язык программирования, который описывает, изменяет и извлекает данные из БД.

Вся информация хранится в реляционных базах данных (БД). SQL – это стандарт языка со спецификацией SQL/PSM. В нём можно создавать процедурные расширения. Первая концепция языка SQL создана для работы «пользователя и базы данных», которая позволяла выполнять такие операции:

  • Создание новой таблицы в базе данных;
  • Внесение в таблицу новой информации;
  • Изменение и удаление записей из базы данных;
  • Поиск и выборка записей в таблице (ах) по определённому условию;
  • Изменение структуры таблиц.

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

Используя базы данных и MySQL, пользователь создаёт связь между прикладными программами и базой данных. Новые версии систем управления базами данных (СУБД) и информационные системы с СУБД, предлагают пользователю усовершенствованные функции и возможности визуального построения запросов.

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

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

Подготовлено по материалам статьи Резервное копирование и восстановление MS SQL Server https://www.backup-solutions.ru/rezervnoe-kopirovanie-i-vosstanovlenie-microsoft-sql-server/

Метки: бэкап, копирование, резервирование

newsn.ru

Как организовать трехуровневое резервное копирование, хранение и восстановление средствами MS SQL Server? Как рассчитать объем под резервные копии?

Сейчас на целевой ИБ делается только полное копирование, делать на основной базе пока не хочу сделал себе копию, балуюсь на тестовой. Я в принципе уже настроил резервирование в соответствии с нужной мне моделью но есть неприятные критичные детали, которые я сделал как мне кажется немного костылем, поэтому дочитайте до конца хотя бы, чтобы своими советами не дублировать мои ранние действия. Модель резервирования которую я организовал: 1 раз в месяц -полный, 1 раз в неделю в выходные - разностный(дифференциальный), с пн по пт, по времени выполнения каждые 30 минут с 09:00 по 18:00 - журналы транзакций. Модель хранения которую я планирую ввести: полные - 6 за полгода от каждого месяца, дифы - 4 за последний месяц, журналы транзакций - все за последнюю неделю с пн по пт.

1) При тестировании когда я делал вручную в SSMS: полные, дифы и журналы, то они сохраняются в "наборе". В качестве теста вручную я делал следующее:1 полный1 диф1 журнал2 диф2 журнал3 журналПри таком раскладе при восстановлении в наборе я перестаю видеть 1 диф и 1 журнал, в случае когда сделан 2 диф. Почему?

1а) Второй момент, с учетом того что оно всё ложится в набор, то при очистке полных или дифов они не различаются, почему? Я так предполагаю что с учетом того что и полный и диф имеют расширение bak они воспринимаются одинаково и каких либо "меток" для их различия я так понимаю нет? То есть если я в планах обслуживания на дифах сделаю очищать всё что раньше 4 недели, то у меня пропадут полные за предыдущие месяцы поскольку они в одной папке в одном наборе будут лежать с дифами.

2) Исходя из п.1 и 1а сделал 3 папки раздельно для полных, дифов, журналов. Каждый ложится в свое место как результат при очистке данных дифы будут очищать только свою папку, полные только свою в соответствии с планами обслуживания с помощью объекта "очистка после обслуживания". Первый костыль!

3) Исходя из п.2 делаю тестовое восстановление с устройства. На этапе восстановлении из полного делаю "перезаписать базу". С параметром для полного и дифа RESTORE WITH NONRECOVERY через раздел восстановления файлы и файловые группы.Проблема конкретно с журналов начинается. При ручном режиме восстанавливать журналы по одному он дает понятное дело через файлы и файловые группы, но с учетом того что их будет очень много, если придется восстанавливать ближе к концу дня конца недели, то вручную восстанавливать по одному журналы заколебаться можно. При попытке восстановить группой журналы транзакций через файлы и файловые группы - ошибка, на скриншоте ниже.По логике вещей как описано в документации и в интернете нужно восстанавливать через раздел восстановления журналы транзакций, так сначала и делал, потом уже баловался с "файлы файловые группы". При попытке восстановить через раздел восстановления журналы транзакций, он изначально был пусть, но я на этой базе туда сюда раза 3-5 постоянно восстанавливал и он таки запомнил мои восстановления слегка наизнанку. Сначала он увидел журнал, который делался до восстановления, потом собственно те журналы, которые я ранее восстанавливал по одному, сейчас да они видятся группой, но даже при этом они не восстанавливаются, скриншот ниже.То есть если не играться с восстановлением, а в реальности на рабочей базе я дойду до момента восстановления журналов транзакций после полного и дифа, в разделе восстановления "журналы транзакций" будет пуст и придется восстанавливать по одному. Второй костыль!

4) Отдельный вопрос как рассчитывать размер резервных копий если для них еще не настраивалось резервирование, чтобы иметь представление какой винт под него выделить. Понятно что при данной модели вопрос встанет насколько сильно изменяются данные. Но если взять просто калькулятор и абстрактную ИБ то каков будет расчет, например база 70 ГБ, база изменяется в день скажем на 15%. - Каков размер полной копии при таких данных при сжатии?- Каков размер дифа?- Каков размер журнала?Мне кажется что расчет в лоб не получится, потому что я может упустил какие-то детали самого SQL SERVER'a?

4а) Второй момент как можно отследить насколько конкретно изменяется ИБ за день? Есть ли какой-то механизм чтобы это не проверять на глазок, мол, вот 15%, то есть не делать предварительно полный, диф, журнал а потом на коленках высчитывать нужный объем, а чтобы сам MSSQL выдал на сколько изменилась ИБ по сравнению с началом дня скажем?

toster.ru

Разностные резервные копии (SQL Server)

 

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

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

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

  • Преимущества

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

  • Разностное резервное копирование баз данных только для чтения

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

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

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

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

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

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

 Примечание

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

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

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

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

Сведения о разностных резервных копиях и базах данных с оптимизированными для памяти таблицами см. в статье Резервное копирование базы данных с оптимизированными для памяти таблицами.

В базах данных только для чтения использование полной резервной копии базы данных самой по себе проще, чем ее использование вместе с разностными резервными копиями. Это объясняется тем, что если база данных находится в режиме «только для чтения», то резервное копирование и прочие операции не в состоянии изменить содержащиеся в файле метаданные. Следовательно, необходимые для разностной резервной копии метаданные (в частности, номер LSN, с которого начинается разностное резервное копирование — номер LSN базовой копии для разностного копирования) хранятся в базе данных master. Если базовая копия для разностного копирования создавалась в тот момент, когда база данных была доступна только для чтения, то битовая карта разностного резервного копирования будет отображать большее число изменений, чем в действительности произошло с момента создания основы резервной копии. Дополнительные данные считываются при резервном копировании, но не записываются в резервную копию, так как столбец differential_base_lsn в системной таблице backupset определяет, какие данные действительно были изменены с момента создания базы.

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

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

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

Если база данных master утрачена, восстановите ее перед восстановлением любой разностной резервной копии пользовательской базы данных.

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

[В начало]

Общие сведения о резервном копировании (SQL Server) Полные резервные копии баз данных (SQL Server) Выполнение полного восстановления базы данных (модель полного восстановления) Выполнение полного восстановления базы данных (простая модель восстановления) Резервные копии журналов транзакций (SQL Server)

technet.microsoft.com