wwwoldi.ru

About Me

Dashy

Hello word I am dashy Guy

Разное

Database sql backup: SQL Server, MySQL and PostgreSQL Backups

alexxlab
No Comments

Содержание

Резервное копирование MS SQL


Дата публикации: 27 декабря 2018 г.


* * *


Данная статья посвящена решениям для восстановления MS SQL. Постараемся рассмотреть основные моменты и важные детали, которые необходимо учесть, при планировании и выборе решения для восстановления базы данных MS SQL.


В рамках планирования аварийного восстановления MS SQL особый интерес представляют два параметра: допустимое время восстановления (recovery time objective — RTO) и допустимая точка восстановления (recovery point objective — RPO).


RPO иными словами, это период времени с момента последнего резервного копирования до момента инцидента, за который будет потерян не критичный объём данных (информации). RTO — это допустимое время, за которое необходимо восстановить работоспособность сервиса/системы с момента инцидента. Оба параметра имеют переменное значение и зависят от требований к той или иной системе. Поэтому для выполнения, установленных RPO и RTO необходимо иметь соответствующий план резервного копирования. На примере, проведём анализ возможных аварийных инцидентов и попробуем выделить точки отказа нашего SQL сервера и способы их решения:


  • аппаратный сбой, физический выход сервера из строя: диски, CPU, системная плата, блок питания и т.д.


  • программный сбой: операционная система, база данных


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


* * *


HIGH AVAILABILITY MS SQL


При высоких требованиях к RPO и RTO (секунды/минуты) единственным решением для обеспечения отказоустойчивости MS SQL является организация технологии высокой доступности сервера (High Availability):


  • Встроенными средствами MS SQL и ОС Windows Server мы можем достичь высокой доступности (High Availability) за счет реализации отказоустойчивого кластера Windows Server Failover Cluster (WSFC) в том числе и с применением технологии AlwaysOn. Отказоустойчивый кластер состоит как минимум из двух узлов/серверов. При сбое активного сервера, происходит аварийное переключение на другой доступный сервер, он становится активным. При этом все службы, которые размещались на сервере автоматически или вручную переносятся на другой доступный узел.


  • В случаи, с виртуальной машиной MS SQL высокую доступность можно обеспечить c помощь средств виртуализации VMware HA-cluster или Hyper-V High Availability. В этом случае при выходе из строя физического сервера, позволяет автоматически запустить виртуальную машину на другом сервере кластера.


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


Преимущества High Availability MS SQL:


  • мгновенное переключение с ноды на ноду, без простоя


  • без зависимости от физических серверов


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


Недостатки High Availability MS SQL:


  • реализации требует дополнительной инфраструктуры и ресурсов


  • высокая стоимость решения по лицензиям и оборудованию


  • более сложное и высоквалифицированное обслуживание


* * *


BACKUP MS SQL


В случаях, когда требования к RTO и RPO не высокие и потребность в High Availability (кластеризации) отсутствует, для обеспечения отказоустойчивости баз данных MS SQL на физическом или виртуальном сервере необходимым условием является наличие резервной копии. Для этого можно задействовать встроенные функции SQL Server или использовать отдельные специализированные системы, поддерживающие различные способы резервного копирования MS SQL, например:


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


Данные системы помогут избежать как аппаратных, так и программных сбоев в работе сервера базы данных.


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


* * *


Регламент backup MS SQL


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


  • Используйте тестовый сервер (песочница) для проверки процедуры восстановления резервных копий


  • Выполняйте ежедневное полное резервное копирование


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


  • Как можно чаще выполняйте резервное копирование журналов транзакций. Журналы транзакций содержат все последние действия, произошедшие в базе данных. Журналы можно использовать для восстановления базы данных на определенный момент времени, и это является самым большим преимуществом. Резервные копии журнала транзакций могут выполняться во время работы системы. Если частота новых данных, создаваемых в вашей базе данных, очень высока, то можно делать резервные копии журнала транзакций каждые 10 минут, в то время как для других баз данных, которые менее активны, такое резервное копирование может выполняться каждые 30 или 60 минут


  • Делайте резервное копирование системных баз данных MS SQL: server, master , model и msdb . Эти базы данных абсолютно необходимы, так как содержат конфигурацию системы, а также информацию о задании SQL Server, которую необходимо будет восстановить в случае полного восстановления системы


* * *


НАСТРОЙКА РЕЗЕРВНОГО КОПИРОВАНИЯ MS SQL С ПОМОЩЬЮ BACKUP EXEC


Скачать


Backup Exec предлагает три метода резервного копирования MS SQL: Full, Differential и Full Copy-only. Метод Full выполняет полное резервное копирование всей базы данных, а Differential выполняет резервное копирование только измененых блоков в базе данных с момента последнего полного резервного копирования. Метод Full Copy-only идентичен полному резервному копированию, но только он не влияет на последующие задания дифференциального резервного копирования.


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


Затем, в настройках параметров (опции) выбрать тип задания (сначала настроить Full потом Differential backup).


Далее, для настройки Full backup на вкладке Microsoft SQL выбрать один из двух методов резервного копирования: Full или Full Copy.


В Backup Exec есть очень важная и полезная функция «Проверка целостности базы до и после выполнения резервного копирования» (Consistency check before/after backup), имеется на выбор четыре варианта:


  • не проводить проверку


  • полная проверка, без учёта индексов


  • полная проверка с учётом индексов


  • только физическая проверка


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


Для настройки differential backup необходимо (аналогично job full backup) сначала добавить новое задание Job Differential, а затем на вкладке Microsoft SQL выбрать один из методов резервного копирования.


В данном списке в первую очередь интересует «Differential — Backup up database changes since the last full» (создание дифференциальной резервной копии на основании полной). Так же возможен вариант создания дифференциальной резервной копии (на уровне блоков) с последующей конвертацией в виртуальную машину «Differential (block-level) — Backup up database changes since the last full – use with convert to virtual machine job».


Еще одним важным параметром является «Log — Back up and truncate transaction log» для резервного копирования журнала транзакций MS SQL.


Мы рассмотрели основные моменты резервного копирования MS SQL. Обращаем внимание, что резервное копирование является частью общего плана аварийного восстановления (DRP), поэтому, перед планированием резервного копирования, необходимо провести полный анализ систем и инфраструктуры, для обеспечения RPO и RTO. А если есть возможность выполнить планирование DRP при разработке системы, это поможет исключить многие проблемы и, возможно, удешевит эксплуатацию системы.


Используемая в статье информация взята из официальных источников:
Отказоустойчивая кластеризация Windows Server с SQL Server
Руководство администратора Backup Exec

Как создать резервную копию всех баз данных экземпляра SQL Server [Вики IT-KB]

microsoft-sql-server:t-sql-script-samples:script-to-backup-all-sql-server-databases

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

В некоторых случаях может возникнуть необходимость создания резервных копий сразу всех баз данных в экземпляре Microsoft SQL Server. В таком случае можно воспользоваться возможностями T-SQL запроса, представленного в статье Simple script to backup all SQL Server databases

В скрипте необходимо изменить значение переменной @path, указав каталог, в который будут сохранены резервные копии всех БД. При указании каталога, в который будут сохраняться резервные копии баз данных, следует помнить о том, что у учётной записи, от имени которой выполняется служба экземпляра SQL Server, должна иметь право на запись в этот каталог.

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

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

TSQL-All-Databases-Backup.sql
-- объявление переменных
DECLARE @name VARCHAR(50)  
DECLARE @path VARCHAR(256)  
DECLARE @fileName VARCHAR(256)  
DECLARE @fileDate VARCHAR(20)
 
-- размещение каталога, в который будут сохранены резервные копии
SET @path = 'C:\Backup\'
 
-- определение формата имени файлов резервной копии
SELECT @fileDate = CONVERT(VARCHAR(20),GETDATE(),112) + '_' + 
REPLACE(CONVERT(VARCHAR(20),GETDATE(),108),':','')
 
DECLARE db_cursor CURSOR READ_ONLY FOR  
SELECT name 
FROM master.sys.databases
WHERE name NOT IN ('master','model','msdb','tempdb') -- исключаемые базы данных
AND state = 0         -- только БД в состоянии Online
AND is_in_standby = 0 -- только БД не находящиеся в режиме Read Only для Log shipping
 
OPEN db_cursor   
FETCH NEXT FROM db_cursor INTO @name   
 
WHILE @@FETCH_STATUS = 0   
BEGIN   
   SET @fileName = @path + @name + '_' + @fileDate + '.BAK'  
   BACKUP DATABASE @name TO DISK = @fileName  
 
   FETCH NEXT FROM db_cursor INTO @name   
END   
 
 
CLOSE db_cursor   
DEALLOCATE db_cursor

Проверено на следующих конфигурациях:

Версия SQL Server
Microsoft SQL Server 2016 Service Pack 2 CU4 (13.0.5233.0)

Автор первичной редакции:
Алексей Максимов
Время публикации: 12.06.2019 12:57

microsoft-sql-server/t-sql-script-samples/script-to-backup-all-sql-server-databases.txt · Последнее изменение: 12.06.2019 13:26 — Алексей Максимов

Как сделать и развернуть из бекапа базу данных

Прочитано:
2 261

Задача: оформить в виде пошаговых инструкций, как сделать и развернуть из бекапа базу данных

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

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

Также я повествую о всех трудностях возникнувших у меня и как я их решал. Публикую все это на своем блоге я создаю своего рода заготовку на будущее (следующие более продуктивные работы в частности перевод инфраструктуры IT на новое на следующих местах работы).

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

Открываю оснастку Microsoft SQL Server Management Studio

Start — All Programs — Microsoft SQL Server 2008 R2 — SQL Server Management Studio, авторизуюсь (у меня настроена двухфакторная авторизация)

Server type: Database Engine

Server name: (local)

Authentication: Windows Authentication

User name: POLYGON\ekzorchik

Password:

и нажимаю Connect

Теперь находясь в оснастке управления сервером баз данных поступаю следующим образом, на имеющейся базе данных (имя базы: telephone) вызываем задачу Back up… (как это сделать смотрите ниже представленный скриншот)

(local) (SQL Server 10.50.1600 — POLYGON\ekzorchik) — Databases — telephone — через правый клик мышью — Tasks — Back up…

После чего настраиваем задачу на создание резервной копии базы данных с именем: telephone

На вкладке General преднастраиваю:

Database: telephone

Backup Type: Full (тип бекапа, я выбираю полный, для меня так проще, я ведь не специалист по администрированию MSSQL чтобы заморачиваться с различными опциями, мне нужна резервная копия и точка)

Backup set:

Name: telephone-Full Database backup

Description: telephone

Destination: Disk — Add — и указываю путь до каталога где я хочу видеть создаваемую резервную копию базы данных: C:\backupbd\Telephone

Переключаюсь на вкладку Options:

Back up to the existing media set: Overwrite all existing backup sets

Reliability: Verify backup when finished

Set backup compression: Compress backup

Как только все параметры задачи предопределены нажимаю кнопку «OK» и в левом углу начинается исполнение задачи:

Чем больше база тем длительней процесс.

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

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

TITLE: Microsoft SQL Server Management Studio

——————————

The backup of database ‘telephone’ completed successfully.

——————————

BUTTONS:

OK

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

(local) (SQL Server 10.50.1600 — POLYGON\ekzorchik) — Databases — telephone — через правый клик мышью — Delete

было отмечено: Delete backup and restore history information for databases

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

Также находясь в оснастке SQL Server Management Studio — через правый клик на Databases — вызываю меню: Restore Database…

To database: указываю как именовать восстанавливаемую базу данных, в моем случае это telephone

Source for restore: From device: и через обзор нахожу в файловой системе резервную копию, в моем случае: C:\backupbd\telephone.bak

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

TITLE: Microsoft SQL Server Management Studio

——————————

The restore of database ‘telephone’ completed successfully.

——————————

BUTTONS:

OK

Это все конечно хорошо, но вот когда баз данных становится много осуществлять их резервное копирование через ручной способ уже не совсем просто, а я бы сказал утомительно и однообразно. Нужно автоматизировать данную процедуру. Когда настраиваем параметры для создания резервной копии в оснастке выше есть возможность те параметры которые я предопределяю (Script — Script Action to File или сочетание клавиш: Ctrl + Shift + F) сохранить в файл с расширение sql. Выглядит его содержимое следующим образом:

BACKUP DATABASE [telephone] TO DISK = N'C:\backupbd\Telephone.bak' WITH NOFORMAT, NOINIT, NAME = N'telephone-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10

GO

declare @backupSetId as int

select @backupSetId = position from msdb..backupset where database_name=N'telephone' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'telephone' )

if @backupSetId is null begin raiserror(N'Verify failed. Backup information for database ''telephone'' not found.', 16, 1) end

RESTORE VERIFYONLY FROM DISK = N'C:\backupbd\Telephone.bak' WITH FILE = @backupSetId, NOUNLOAD, NOREWIND

GO

изменяя его содержимое под другие базы данных получаем sql файлы которые запускаем так:

sqlcmd -S SEVERNAME -U UserName -P Password -i, а вообще лучше ознакомиться самостоятельно с мануалом так будет намного полезнее чем приводить все возможные комбинации аутентификации в сервисе баз данных MS SQL 2008 R2

(На заметку: если используется двухфакторная авторизация в оснастке Management Studio, то команда:)

C:\Windows\system32>sqlcmd -i c:\1\backup.sql

10 percent processed.

20 percent processed.

30 percent processed.

40 percent processed.

50 percent processed.

60 percent processed.

70 percent processed.

80 percent processed.

90 percent processed.

Processed 497048 pages for database ‘telephone’, file ‘telephone’ on file 1.

100 percent processed.

Processed 2 pages for database ‘telephone’, file ‘telephone_log’ on file 1.

BACKUP DATABASE successfully processed 497050 pages in 111.659 seconds (34.777 M

B/sec).

The backup set on file 1 is valid.

А запустить скрипт через оснастку можно так:

находясь в оснастке SQL Server Management Studio — File — Open — File… — указываем местонахождение скрипта (в моем случае: c:\1\backup.sql) и нажимаем на элемент Execute, смотрите скриншот чтобы понять где этот элемент находится.

 

На заметку: По такому принципу можно создать задание где указать все параметры и базы и сохранить задание в командный файл sql.

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

DECLARE @pathName NVARCHAR(512)

SET @pathName = 'C:\backupbd\telephone_' + Convert(varchar(8), GETDATE(), 112) + '.bak'

BACKUP DATABASE [telephone] TO DISK = @pathName WITH NOFORMAT, NOINIT, NAME = N'telephone',SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10

После выполнения данного скрипта резервная копия базы данных приняла вид: telephone_20151022.bak — что мне и требовалось.

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

sqlbackup.bat

echo off

sqlcmd -i c:\script\telephone.sql

sqlcmd -i c:\script\<database2>.sql

sqlcmd -i c:\script\<database3>.sql

sqlcmd -i c:\script\<database4>.sql

exit

который в последствии можно прикрутить к планировщику заданий Windows системы.

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

Создание резервных копий с помощью утилиты RMAN (Recovery Manager)

oracle-dba.ru

  • Vagrant
  • Docker
  • Kubernetes
  • Добавить знания

    • Добавить свои знания на сайт
    • Завести свой блог на поддомене
    • Разместить резюме на нашем сайте
  • Общение

    • Чат
    • Форум
  • Скрипты

    • Демонстрационные СХЕМЫ
    • Коллекция скриптов для Oracle DBA
    • Коллекция PL/SQL скриптов
  • Карта сайта

    • Все разделы
    • DataBase
    • WebLogic
    • Business Intelligence

Резервное копирование транзакционного лога — AUsevich

В данной статье рассматривается как настроить задачу резервного копирования транзакционного лога при использовании полной модели восстановления в СУБД MS SQL Server. Статья является продолжением статьи «Перечень необходимых задач регламентного обслуживания MS SQL Server».

Предисловие

Как ранее описывалось, в случае выбора полной модели восстановления, при использовании СУБД MS SQL Server, необходимо выполнять задачу резервного копирования транзакционного лога. Данная необходимость обусловлена тем, что журнал транзакций будет расти пока не будет выполнен его бэкап, или же он не займет все место на диске и, как результат, СУБД упадет с ошибкой. Правильной периодичностью выполнения данного задания считается такая периодичность, при которой файл транзакционного лога не будет расти, т.е. будет сохранять свой размер, но не реже периодичности создания дифференциальной/полной резервной копии. Таким образом, данная задача сводится к подбору оптимального соотношения значений: размера транзакционного лога, периодичности его резервного копирования и количества транзакций в базе данных (проще говоря, активности пользователей при работе с БД). В моем случае, задание выполняется каждый час.

Настройка задания

Добавим основной, общий для одной базы данных, план обслуживания, который можно назвать именем базы данных, и добавим в него субплан «LogBackUp», после чего назначим ему расписание. В моем случае, расписание задано следующего вида: «Понедельник — Суббота, с 9:00 до 21:00, каждый час». Подробнее о создании плана обслуживания написано в статье «Механизм «Планы обслуживания» и механизм заданий MS SQL Server»

Добавление субплана резервного копирования транзакционного логаСвойства расписания субплана

После этого, из панели инструментов Планов обслуживания перенесем задание «Резервное копирование базы данных» (Back Up Database Task) в рабочую область субплана (т.е. добавим задание в наш субплан).

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

Далее, двойным щелчком по задаче, откроем задачу для редактирования.

На вкладке «Общее» (General) укажем:

  1. «Тип резервного копирования» (Backup type): «Журнал транзакций» (Transaction log)
  2. В «базы данных» (Databases): выберем требуемые базы данных
  3. В «Назначение» бэкапа: «Диск» (Disk)

Вкладка «Общее» задачи резервного копирования базы данных

На вкладке «Параметры носителя» (Destination) укажем:

  1. «Папку» (Folder): где будут храниться резервные копии транзакционного лога
  2. «Расширение файлов» (file extension) транзакционного лога

Вкладка «Параметры носителя» задачи резервного копирования базы данных

На вкладке «Параметры резервного копирования» (Options) можно:

  1. Установить «режим сжатия файла» (Set backup compression): рекомендую сжимать, чтобы не занимал лишнего места
  2. Установить «срок действия набора данных» (Backup set will expire): в течение данного периода времени SQL защитит от перезаписи этот набор данных другими наборами резервных копий. Но это не означает что устаревшие наборы данных будут автоматически удалены, для автоматического удаления необходимо использовать задание «Очистка после обслуживания» (Maintenance cleanup task).
  3. Установить флаг «Архивная копия только для копирования» (Copy-only backup): в нашем случае ставить не надо. SQL создает копию не влияющую на последовательность восстановления.
  4. Установить флаг «Проверить копию после завершения» (Verify backup integrity): рекомендуется установить, для повышения надежности. После выполнения задания копия будет проверена на целостность.
  5. Установить режим «Шифрования» (Encryption): используется для шифрования файла бэкапа.

Вкладка «Параметры резервного копирования» задачи резервного копирования базы данных

После вышеприведенных действий остается только сохранить наш план обслуживания и проверить его работоспособность.

Автоматическая проверка резервных копий базы данных SQL

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

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

  1. Команда RESTORE VERIFYONLY — проверяет, можно ли прочитать и восстановить резервную копию базы данных SQL

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

     ВОССТАНОВИТЬ ТОЛЬКО
С ДИСКА = 'E: \ Test \ AdventureWorks2012_Full.бак '

    Если резервная копия действительна, ядро ​​СУБД SQL Server возвращает:

    Действует резервный набор для файла 1

    Обратите внимание, однако, что структура данных и надежность не могут быть проверены таким образом

  2. Чтобы проверить структуру данных и надежность в резервной копии SQL Server, резервную копию необходимо создать с помощью WITH CHECKSUMS (проверяет контрольные суммы страниц и создает резервную копию). При добавлении в RESTORE VERIFYONLY оператор проверяет целостность данных в резервной копии.

    Если вы выполните

     ВОССТАНОВИТЬ ТОЛЬКО
С ДИСКА = 'E: \ Test \ AdventureWorks2012_Full.бак '
С КОНТРОЛЬНОЙ СУММОЙ

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

     Msg 3187, уровень 16, состояние 1, строка 1
RESTORE WITH CHECKSUM нельзя указать, потому что резервный набор
не содержать информации о контрольной сумме.
Msg 3013, уровень 16, состояние 1, строка 1
VERIFY DATABASE завершает работу ненормально.

    Если резервная копия базы данных создана с помощью WITH CHECKSUM и целостность данных проверена, отображается следующее сообщение:

    Действует резервный набор для файла 1

    Имейте в виду, однако, что WITH CHECKSUM увеличивает накладные расходы, увеличивает размер резервных копий и увеличивает время создания резервной копии (важно для больших баз данных)

    Так как RESTORE VERIFYONLY не проверяет всю информацию заголовка в резервной копии, есть вероятность, что резервная копия недействительна и ее невозможно восстановить, даже если инструкция выполнена успешно.

  3. Надежный способ проверить резервную копию базы данных — восстановить ее.Вы также можете немедленно запустить DBCC CHECKDB для восстановленной базы данных, чтобы убедиться, что все в порядке. Если оба действия выполнены успешно, резервное копирование в порядке. В отличие от проверки резервных копий RESTORE VERIFYONLY (где проверяются только резервные копии, созданные с помощью WITH CHECKSUM), этот метод можно использовать для резервных копий, созданных без WITH CHECKSUM

Используйте SQL Server Management Studio для восстановления резервных копий

Чтобы автоматически создать резервную копию базы данных SQL Server, восстановить и проверить ее, используйте T-SQL и запланируйте задание SQL:

  1. Чтобы создать резервную копию базы данных, щелкните правой кнопкой мыши базу данных в Object Explorer и выберите Tasks | Резервное копирование

  2. Укажите тип и место хранения резервной копии

  3. Откройте раскрывающееся меню Сценарий и выберите действие сценария для задания

  4. Автоматически создается новое задание (первый шаг — создание резервной копии базы данных)

  5. Убедитесь, что для шага При успешном действии параметр Перейдите к следующему шагу и нажмите ОК

  6. Щелкните Новый , чтобы добавить новый шаг, восстанавливающий резервную копию базы данных SQL, созданную на шаге 1.Команда должна содержать MOVE, поскольку база данных с таким же путем и именами файлов уже существует на экземпляре SQL Server

    .

     ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ AdventureWorks2012_Test
   ОТ ДИСКА = 'E: \ Test \ AdventureWorks2012_Full.bak'
  С ВОССТАНОВЛЕНИЕМ,
ПЕРЕМЕСТИТЕ 'AdventureWorks2012_Data' В 'E: \ test \ AdventureWorks2012_Data.mdf',
ПЕРЕМЕСТИТЕ «AdventureWorks2012_Log» в «E: \ test \ AdventureWorks2012_Log.ldf»
GO

  7. Нажмите ОК

  8. Добавьте третий шаг для проверки логической и физической целостности всех объектов в восстановленной базе данных.Тип шага — Transact-SQL, а команда:

    .

     DBCC CHECKDB (AdventureWorks2012_Test)

  9. В диалоговом окне Job перейдите на вкладку Расписания вкладка

  10. Укажите имя задания, время выполнения и частоту

  11. Нажмите ОК

  12. Чтобы убедиться, что задание SQL создано успешно, щелкните его правой кнопкой мыши в обозревателе объектов и выберите Начать задание на этапе

  13. Выберите первый шаг.Если все шаги выполнены успешно, статус задания будет «Успешно»

    .

  14. Восстановленная база данных будет указана среди других баз данных в обозревателе объектов

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

Используйте ApexSQL Restore для восстановления резервных копий

ApexSQL Restore — это инструмент восстановления SQL Server, который присоединяет собственные и сжатые в собственном коде резервные копии баз данных SQL (полные и дифференциальные) и резервные копии журналов транзакций как действующие базы данных.После присоединения резервные копии будут доступны через SQL Server Management Studio, Visual Studio или любой сторонний инструмент. ApexSQL Restore Интерфейс командной строки позволяет планировать восстановление резервных копий с помощью заданий SQL

  1. Создайте пакетный файл (например, с именем RestoreBatch.bat), используя оператор в следующем формате:

    «<путь установки ApexSQL Restore> \ ApexSQLRestore.com» / server: <имя сервера> / user: <имя пользователя> / пароль: <пароль SQL Server> / database: <имя базы данных> / backup: <путь к файлу резервной копии и имя> / restorepath: <путь для файлов восстановленной базы данных> / database: <имя восстановленной базы данных> / attach

    Например, чтобы восстановить файл AdventureWorks2012_Full.bak, хранящуюся в папке E: \ Test, в экземпляр Fujitsu \ SQL2012 как базу данных с именем AdventureWorks2012_Restored, а для хранения новых файлов MDF и LDF в папке E: \ Test сохраните следующие

    «C: \ Program Files (x86) \ ApexSQL \ ApexSQLRestore2012 \ ApexSQLRestore.com» / сервер: Fujitsu \ SQL2012 / пользователь: sa / пароль: sqladmin / backup: E: \ Test \ AdventureWorks2012_Full.bak / restorepath: E: \ Test / database: AdventureWorks2012_Restored / attach

  2. В SQL Server Management Studio создайте задание для создания резервной копии базы данных SQL, используя шаги с 1 по 5, приведенные в Используйте SQL Server Management Studio для восстановления резервных копий раздел
  3. На вкладке Steps диалогового окна Job щелкните New
  4. Укажите имя шага и выберите Операционная система (CmdExec) в качестве типа

  5. Щелкните Открыть , затем перейдите к RestoreBatch.bat файл

  6. Создайте новый шаг для проверки целостности восстановленной базы данных с помощью

     DBCC CHECKDB (AdventureWorks2012_Restored)

  7. Если вы хотите удалить базу данных после проверки, добавьте новый шаг, который будет выполняться:

     УДАЛЕНИЕ БАЗЫ ДАННЫХ AdventureWorks2012_Restored

  8. После создания всех 4 шагов запланируйте выполнение задания, как описано в шаге 10 в разделе «Использование SQL Server Management Studio для восстановления резервных копий».

Как показано, ApexSQL Restore также использует задания SQL Server для автоматизации проверки базы данных.Преимущества проверки резервной копии ApexSQL Restore — более быстрое восстановление и меньшее использование места на жестком диске. Экономия места до 99%

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

2 августа 2013 г.

Резервное копирование базы данных SQL в удаленное место — Статьи по SQL

Название звучит безумно? Вы могли подумать, что эта тема очень простая? Да, вы правы, однако некоторые люди до сих пор поднимают этот вопрос на форумах.Я давно вижу этот вопрос на форумах и подумываю поделиться решением здесь, чтобы люди могли найти его (потому что Google — наш первый технический учитель или поставщик мгновенных решений: P).

Хорошо, почему SQL не может использовать мои локальные диски (рабочий стол) для резервного копирования? Хороший вопрос! Когда вы устанавливаете SQL Server, диски в области действия ограничиваются сервером, на котором вы устанавливаете SQL-сервер, допустим, вы устанавливаете на Server1, тогда SQL может получить доступ ко всем дискам, существующим в Server1, это концепция.Даже в проводнике Windows обычно нельзя напрямую просматривать другие системные диски, однако вы можете использовать символ $ (например.) \ Server1 \ c $) для доступа к дискам, но для этого требуются права администратора на целевом сервере.

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

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

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

.

Обязательное условие

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

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

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

 РЕЗЕРВНАЯ БАЗА ДАННЫХ публикуется на диск = '\\ sagarpc \ remotebackup \ Pubs.bak'

Плюсы

Минусы

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

  • SQL Время резервного копирования прямо пропорционально пропускной способности сети

  • Если ваша служба SQL работает в учетной записи службы Localsystem, вы не можете использовать этот метод

Создание общего сетевого ресурса в SQL Server (уровень сервера)

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

Обязательное условие

  • Создайте сетевой ресурс на сервере

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

Как только все будет в порядке, начните делать резервную копию. Мы рассмотрим тот же сценарий для копирования базы данных Pubs, сначала я сделаю резервную копию на локальном диске сервера (папка, которая сделана как общий сетевой ресурс сервера, в данном случае Ive shared D: Backups folder), затем я вручную сопоставлю общий ресурс с моего рабочего стола, чтобы скопировать его.

 Публикации РЕЗЕРВНОЙ БАЗЫ ДАННЫХ НА ДИСК = 'D: \ Backups \ Pubs.bak'

Плюсы

  • SQL Server не требует ожидания сетевых задержек

  • SQL Время резервного копирования не прямо пропорционально пропускной способности сети

  • Вы можете использовать этот метод, даже если служба SQL использовала учетную запись локальной системы

Минусы

  • Вам необходимо вручную скопировать резервную копию на локальную машину

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

Использовать мастер публикации базы данных

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

Обязательное условие

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

Плюсы

  • Довольно прямо
  • Вы можете использовать Windows или аутентификацию SQL
  • Для учетной записи службы SQL

    • не требуются повышенные права доступа

  • Вы можете использовать это, даже если учетная запись службы SQL использует учетную запись локальной системы

Минусы

  • Необходимо установить ПО
  • Напрямую зависит от скорости сети
  • Это займет больше времени по сравнению с обычным резервным копированием
  • Рекомендуется только для базы данных небольшого размера

SQL Server 2016: резервное копирование базы данных

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

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

Создание резервной копии через графический интерфейс

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

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

  2. Проверьте настройки резервного копирования

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

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

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

  3. Резервное копирование завершено

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

    Нажмите ОК , чтобы закрыть сообщение и диалоговое окно.

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

Резервное копирование базы данных с помощью Transact-SQL

  • Вы можете выполнить такое же резервное копирование, как указано выше, с помощью SQL.

    Для этого откройте новое окно запроса и выполните инструкцию BACKUP .

    Оператор BACKUP принимает различные параметры (точно так же, как параметр GUI), но вы также можете запустить простое резервное копирование с минимальным кодом.

    Образец кода

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

    После запуска этого кода файл резервной копии будет расположен в указанном месте.

    РЕЗЕРВНАЯ БАЗА ДАННЫХ Музыка
    НА ДИСК = ‘C: \ Program Files \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ Backup \ Music.bak’;

    Полный синтаксис оператора BACKUP можно увидеть на веб-сайте Microsoft.

Резервное копирование базы данных с помощью PowerShell

SQL Server 2016 поддерживает Windows PowerShell, оболочку сценариев, обычно используемую для автоматизации задач администрирования и развертывания.

Язык PowerShell поддерживает более сложную логику, чем сценарии Transact-SQL, что дает вам возможность создавать более сложные сценарии для резервного копирования и других задач.

  1. Открыть PowerShell

    Щелкните правой кнопкой мыши базу данных и выберите Запустить Powershell .

  2. Выполнить команду резервного копирования

    Введите команду для создания резервной копии и нажмите Введите (или Верните , в зависимости от вашей клавиатуры).

    Резервное копирование запустится немедленно.

    Образец кода

    Следующий код создаст резервную копию, как и в предыдущих примерах.Просто замените MyServer именем вашего сервера.

    После запуска этого кода файл резервной копии будет расположен в месте по умолчанию.

    Резервное копирование-SqlDatabase -ServerInstance MyServer -Database Music

    Также можно указать местоположение

    Резервное копирование-SqlDatabase -ServerInstance MyServer -Database Music -BackupFile ‘C: \ Program Files \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ Backup \ Music.bak ‘

    Вы также можете указать -BackupAction Database , чтобы явно указать, что это полная резервная копия. Однако это вариант по умолчанию.

    Полную документацию по команде Backup-SqlDatabase можно найти на веб-сайте Microsoft.

Перезапись файлов резервных копий

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

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

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

Есть опция, позволяющая перезаписать существующий файл.

  • Используя графический интерфейс пользователя , щелкните Параметры носителя в левом меню диалогового окна Резервное копирование базы данных и выберите Перезаписать все существующие наборы резервных копий в разделе Перезаписать носитель .
  • Используя SQL, добавьте WITH INIT в оператор SQL.
  • Используя Powershell , добавьте в команду -Initialize .

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

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

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

Резервное копирование базы данных в виде дампа SQL (пакетные сценарии)

Вы можете создать дамп базы данных для резервного копирования или для передачи данных на другой сервер SQL (не обязательно на сервер MySQL). Дамп будет содержать операторы SQL для создания таблицы и / или заполнения таблицы. Чтобы создать дамп, выберите базу данных или таблицу в обозревателе объектов и выберите База данных -> Резервное копирование / экспорт -> Резервное копирование базы данных в виде дампа SQL… Эта опция также доступна в Таблица -> Резервное копирование / экспорт -> Резервное копирование базы данных как SQL Дамп… или просто нажмите Ctrl + Alt + E .

Имя базы данных: Выберите исходную базу данных из списка доступных баз данных.

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

Экспорт в файл: Укажите имя файла экспорта.

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

Параметры, влияющие на источник:

  • Заблокировать все таблицы для чтения: LOCK будет генерироваться для одной таблицы (той, для которой в настоящее время генерируются операторы INSERT).
  • Очистить журналы перед созданием дампа: Использование этой опции гарантирует, что все ожидающие изменения данных будут записаны на диск до начала резервного копирования.
  • Одиночная транзакция: Параметр (аналог «mysqldump» «-? — single-transaction») действует только с механизмами хранения транзакций (такими как InnoDB). Будет выполнено резервное копирование всех таблиц из их состояния на момент начала резервного копирования. Этот параметр обеспечит согласованность между таблицами с ограничениями Foreing Key CONSTRAINT. Опции одиночной транзакции и опции LOCK ALL Tables являются взаимоисключающими.

Параметры, записанные в файл:

  • Включить оператор «USE database»: Чтобы вставить имя базы данных USE в сценарий.
  • Включить оператор «CREATE database»: Чтобы вставить CREATE DATABASE в сценарий.
  • Установить FOREIGN_KEY_CHECKS = 0: Этот параметр следует всегда проверять, если таблицы с внешними ключами копируются, поскольку нет способа гарантировать, что «родительская» таблица записывается в файл перед «дочерней таблицей».Если они записаны в обратном порядке, восстановление не удастся, если этот параметр не выбран.
  • Добавить блокировку вокруг оператора (ов) INSERT: Это гарантирует, что никакие другие клиенты не будут иметь доступа WRITE к таблицам во время восстановления, пока они не будут полностью восстановлены.
  • Создать оператор (ы) массовой вставки: Если этот параметр отмечен, данные из большего количества строк будут записаны в один оператор INSERT. Каждой инструкции INSERT будет разрешено вырасти до размера, указанного в параметре «Макс.размер настройки BULK INSERTS.
  • Включить оператор (и) «DROP»: Вставляет оператор (ы) DROP в скрипт, чтобы сначала удалить именованные объекты перед восстановлением скрипта. Эта опция влияет только на базы данных — таблицы и другие объекты (представления, «Сохраненные программы»).
  • Игнорировать DEFINER: Это возможность игнорировать предложение DEFINER для объектов базы данных. Обратите внимание, что целевой сервер затем создаст DEFINER как текущего пользователя SQLyog при создании объекта..

Дополнительные возможности:

  • Префикс с отметкой времени: Это обеспечит добавление отметки времени, то есть даты и времени резервного копирования, к имени созданного файла .sql.
  • Файл на объект: Этот параметр позволяет создавать резервные копии данных нескольких файлов в файлах SQL. SQLyog сгенерирует файл с именем tbl_ (имя_файла) .sql для каждого файла.
    Если выбраны оба, то папка будет создана по имени файла с меткой времени в имени этой папки, и каждый из файлов внутри этой папки будет иметь метку времени в качестве префикса в имени.

В диалоговом окне SQL Dump сначала выберите объект (ы), например, таблицы, представления, сохраненные процессы, функции, триггеры и события, для резервного копирования из исходной базы данных. Вы можете Выбрать все / Отменить выбор, установив флажки на узлах дерева, чтобы быстро выбрать объект (ы). Теперь выберите файл, в который вы хотите экспортировать данные.

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

Вы даже можете запланировать процесс Backup , используя параметр Scheduled Backups.

Резервное копирование базы данных SQL Server — Cybarlab

Резервное копирование является важной частью любой системы баз данных. Это уменьшает случайную потерю данных. В этой статье описывается , как создать резервную копию базы данных в SQL-запросе . Краткое содержание статьи:

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

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

  1. SQL Server Management Studio
  2. SQL-скрипты

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

Сценарий SQL для резервного копирования одной базы данных SQL Server
Следующий запрос SQL будет выполнять резервное копирование конкретной базы данных SQL. Простая команда для этого — «BACKUP DATABASE DatabaseName». Параметр «НА ДИСК» указывает, что резервная копия должна быть записана на диск по пути. Путь означает расположение и имя файла. Сценарий SQL:

 РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ MyDataBaseName TO DISK = 'D: /FileName.bak'

Скрипт SQL для резервного копирования всех баз данных SQL Server
Этот простой запрос создаст резервную копию всех баз данных, существующих на сервере SQL, кроме системных баз данных (master, model, msdb, tempdb) или мы также можем создать собственный список, который нужно пропустить.Этот сценарий T-SQL или SQL создаст резервную копию всех баз данных SQL Server. Нам нужно изменить Путь, чтобы установить требуемый каталог для резервного копирования. Формат имени файла — имя_базы_данных_ГГГГММДД.BAK.

 DECLARE @DBName VARCHAR (250) - Имя базы данных
DECLARE @Path VARCHAR (250) - путь для файлов резервных копий
DECLARE @FileName VARCHAR (250) - имя файла для резервного копирования
DECLARE @DateTime VARCHAR (20) - Текущая дата и время

НАБОР @Path = 'D: \'
ВЫБЕРИТЕ @DateTime = CONVERT (VARCHAR (20), GETDATE (), 112)

ОБЪЯВЛЕНИЕ КУРСОРА db_cursor ДЛЯ
ВЫБЕРИТЕ имя
ОТ мастера.dbo.sysdatabases
ГДЕ имя НЕ В ('master', 'model', 'msdb', 'tempdb')

ОТКРЫТЬ db_cursor
ПОЛУЧИТЬ ДАЛЕЕ ИЗ db_cursor В @DBName
ПОКА @@ FETCH_STATUS = 0
НАЧАТЬ
НАБОР @FileName = @Path + @DBName + '_' + @DateTime + '.BAK'
РЕЗЕРВНАЯ БАЗА @DBName НА ДИСК = @FileName
ПОЛУЧИТЬ ДАЛЕЕ ИЗ db_cursor В @DBName
КОНЕЦ
ЗАКРЫТЬ db_cursor
DEALLOCATE db_cursor

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

Стратегия резервного копирования и восстановления базы данных SQL Azure — статьи TechNet — США (английский)

База данных

Windows Azure SQL требует собственной стратегии резервного копирования и восстановления из-за наличия среды и доступных инструментов.Во многом риски были опосредованы тем, что база данных находилась в центрах обработки данных Microsoft. Инструменты, которые у нас есть сегодня, охватывают
другие факторы риска, однако появляются более совершенные инструменты, которые значительно облегчают работу.

Для получения последней информации о стратегии резервного копирования и восстановления базы данных SQL см. Статью «Резервное копирование и восстановление базы данных SQL Windows Azure» в Базе данных Windows Azure SQL.
Библиотека MSDN.

Заметка
Если вы хотите внести свой вклад в эту страницу, используйте
Изменить вкладку вверху (требуется вход).Если вы хотите оставить отзыв о данной документации, отправьте электронное письмо по адресу

[email protected] или используйте поле «Комментарий» внизу этой страницы (требуется вход в систему).

Введение

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

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

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

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

Общие положения

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

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

Переход с SQL Server

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

Заказчик в конечном итоге несет ответственность за схему и данные в базе данных SQL, однако Microsoft через текущую базу данных SQL

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

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

Microsoft поддерживает базовую инфраструктуру SQL Azure в центре обработки данных. Заказчик не несет ответственности за эти общие задачи, выполняемые на локальном SQL Server, такие как: резервное копирование операционной системы, основной базы данных, журналов транзакций,
или tempdb. Фактически, мы не создаем резервную копию операционной среды, она создается в образе, а машины переустанавливаются и добавляются в центры обработки данных еженедельно из образа.

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

Отказ оборудования

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

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

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

Форс-мажор

Текущая версия SQL Azure
В соглашении об уровне обслуживания есть исключение для факторов, находящихся вне разумного контроля Microsoft, например, форс-мажорных обстоятельств. Форс-мажор — чрезвычайное событие или обстоятельство, не зависящее от сторон, такое как война, забастовка, бунт, преступление или
событие (например, наводнение, землетрясение, извержение вулкана). Следствием этого является то, что центр обработки данных поврежден таким образом, что базы данных невозможно восстановить из реплик или резервных копий на месте.В настоящее время SQL Azure не хранит резервных копий вне сайта; этот
ответственность клиента.

Один из вариантов создания резервной копии вне офиса — использование
Синхронизация данных SQL. Без кода вы можете настроить свою базу данных SQL для синхронизации с одной или несколькими базами данных SQL в любом из центров обработки данных Windows Azure. Таким образом, вы получаете возможность резервного копирования в удаленные центры обработки данных, предотвращая потерю данных.
Форс-мажор. Синхронизация происходит по фиксированному расписанию и перемещает изменения в базу данных только после завершения полного перемещения данных.В этом смысле он работает как дифференциальная резервная копия. Вы также можете использовать SQL Data Sync для синхронизации с локальной
SQL Server; предоставляя вам локальную резервную копию. Увидеть
это сообщение в блоге для получения дополнительной информации о настройке службы синхронизации данных SQL.

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

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

Ошибка пользователя

Типичная причина восстановления базы данных — не сбой или катастрофа; это вызвано ошибкой пользователя. Либо ошибочная команда, такая как DROP DATABASE, изменения схемы, которые не выполняются правильно (что приводит к потере данных), либо код, который искажает данные.Создание резервных копий
Ответственность за защиту от ошибок пользователя несет заказчик, и ее необходимо учитывать при написании стратегии резервного копирования и восстановления.

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

  1. Копии базы данных
  2. Служба импорта / экспорта

Копии базы данных

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

Transact SQL выглядит так:

СОЗДАТЬ БАЗУ ДАННЫХ имя_назначения_данных

КАК КОПИЯ [имя_сервера_источника.] source_database_name

Чтобы скопировать базу данных Adventure Works на тот же сервер, я выполняю это:

СОЗДАТЬ БАЗУ ДАННЫХ [AdvetureWorksBackup] КАК КОПИЯ [AdventureWorksLTAZ2008R2]

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

Контроль копирования

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

Пример запроса выглядит так:

ВЫБРАТЬ * ИЗ sys.dm_database_copies

Вот мой результат из копии Adventures Works выше:

Разрешения, необходимые для копирования базы данных

Когда вы копируете базу данных на другой сервер базы данных SQL, на исходном и целевом серверах должны существовать точно такие же имя пользователя и пароль для выполнения команды. Логин должен иметь
db_owner разрешений на исходном сервере и dbmanager на целевом сервере. Подробнее о разрешениях можно найти в статье MSDN:
Копирование баз данных в базе данных Windows Azure SQL.

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

Служба импорта / экспорта

Post SQL Database Q4 2011 Service Release, новая служба была представлена ​​для прямого импорта или экспорта между базой данных SQL и хранилищем BLOB-объектов Windows Azure.Эта функция является бесплатной службой, доступной через портал управления Azure, и экспортирует все поддерживаемые
объекты схемы базы данных и данные таблиц в одном пакете файла с расширением .BACPAC. Следует отметить, что файл .BACPAC не эквивалентен резервной копии, поскольку он не содержит журнала транзакций и данных истории и не является согласованным с точки зрения транзакций.
сам по себе.

В настоящее время целью экспорта является хранилище BLOB-объектов, но в будущем оно будет расширено.Что касается необходимости автоматизации, услуга, предоставляемая на портале управления, предназначена только для экспорта / импорта по запросу и может быть автоматизирована с помощью DAC.
Клиентские инструменты / библиотеки. Подробное объяснение того же можно найти на
Как использовать импорт и экспорт приложений уровня данных с базой данных Windows Azure SQL.

Импорт / экспорт

Выполнить импорт / экспорт так же просто, как развернуть узел сервера на портале управления, выбрать базу данных и щелкнуть любую кнопку импорта / экспорта.Экспорт сохраняет базу данных в хранилище BLOB-объектов, а импорт восстанавливает базу данных обратно в базу данных SQL.
из хранилища BLOB-объектов. После отправки запроса на импорт / экспорт пользователю предоставляется идентификатор GUID для отслеживания состояния импорта / экспорта

.

Мониторинг службы

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

Разрешения, необходимые для импорта / экспорта

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

No related posts.

Share :

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *