Разное

Бэкап базы: Разбираемся с утилитами для бэкапа баз данных — «Хакер»

20.06.2018
Разбираемся с утилитами для бэкапа баз данных — «Хакер»

Содержание

Содержание статьи

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

 

Виды бэкапов баз данных

Для начала разберемся с тем, какие вообще бывают бэкапы. Сервер баз данных не является обычным десктопным приложением, и, чтобы обеспечить выполнение всех свойств ACID (Atomic, Consistency, Isolated, Durable), используется ряд технологий, а поэтому создание и восстановление БД из архива имеет свои особенности. Существуют три различных подхода к резервному копированию данных, каждый из которых имеет свои плюсы и минусы.

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

Физический бэкап (уровня файловой системы) — копирование файлов, которые СУБД использует для хранения данных в базе данных. Но при простом копировании игнорируются блокировки и транзакции, которые, скорее всего, будут неправильно сохранены и нарушены. При попытке присоединить этот файл он будет в несогласованном состоянии и приведет к ошибкам. Чтобы получить актуальный бэкап, базу данных нужно остановить (можно уменьшить время простоя, использовав два раза rsync — вначале на работающей, потом на остановленной). Недостаток этого метода очевиден — нельзя восстановить определенные данные, только всю базу данных. При старте БД, восстановленной из архива файловой системы, нужно будет провести проверку на целостность. Здесь используются разные вспомогательные технологии. Например, в PostgreSQL логи упреждающей журнализации WAL (Write Ahead Logs) и специальная функция (Point in Time Recovery — PITR), позволяющая вернуться к определенному состоянию базы. С их помощью легко реализуется третий сценарий, когда бэкап уровня файловой системы объединяется с резервной копией WAL-файлов. Вначале восстанавливаем файлы резервной копии файловой системы, а затем при помощи WAL база приводится к актуальному состоянию. Это чуть более сложный подход для администрирования, но зато нет проблем с целостностью БД и восстановлением баз до определенного времени.

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

 

Barman

Сайт: pgbarman.org, sf.net/projects/pgbarman

Лицензия: GNU GPL

Поддерживаемые СУБД: PostgreSQL

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

Barman (backup and recovery manager) — внутренняя разработка компании 2ndQuadrant, предоставляющей услуги на базе PostgreSQL. Предназначен для физического бэкапа PostgreSQL (логический не поддерживает), архивирования WAL и быстрого восстановления после сбоев. Поддерживаются удаленный бэкап и восстановление нескольких серверов, функции point-in-time-recovery (PITR), управление WAL. Для копирования и подачи команд на удаленный узел используется SSH, синхронизация и бэкап при помощи rsync позволяет сократить трафик. Также Barman интегрируется со стандартными утилитами bzip2, gzip, tar и подобными. В принципе, можно использовать любую программу сжатия и архивирования, интеграция не займет много времени. Реализованы различные сервисные и диагностические функции, позволяющие контролировать состояние сервисов и регулировать полосу пропускания. Поддерживаются Pre/Post-скрипты.

Конфигурационный файл Barman

Barman написан на Python, управление политиками резервного копирования производится при помощи понятного INI-файла barman.conf, который может находиться в /etc или домашнем каталоге пользователя. В поставке идет готовый шаблон с подробными комментариями внутри. Работает только на *nix-системах. Для установки в RHEL, CentOS и Scientific Linux следует подключить EPEL — репозиторий, в котором содержатся дополнительные пакеты. В распоряжении пользователей Debian/Ubuntu официальный репозиторий:

$ sudo apt-get install barman

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

 

Sypex Dumper

Сайт: sypex.net/ru/products/dumper

Лицензия: BSD

Поддерживаемые СУБД: MySQL

Вместе с MySQL поставляются утилиты mysqldump, mysqlhotcopy, позволяющие легко создать дамп базы данных, они хорошо документированы, и в интернете можно найти большое количество готовых примеров и фронтендов. Последние позволяют новичку быстро приступить к работе. Sypex Dumper представляет собой PHP-скрипт, позволяющий легко создать и восстановить копию базы данных MySQL. Создавался для работы с большими базами данных, работает очень быстро, понятен и удобен в использовании. Умеет работать с объектами MySQL — представлениями, процедурами, функциями, триггерами и событиями.

Еще один плюс, в отличие от других инструментов, при экспорте производящих перекодирование в UTF-8, — в Dumper экспорт производится в родной кодировке. Результирующий файл занимает меньше места, а сам процесс происходит быстрее. В одном дампе могут быть объекты с разными кодировками. Причем легко импорт/экспорт произвести в несколько этапов, останавливая процесс во время нагрузки. При возобновлении процедура начнется с места остановки. При восстановлении поддерживается четыре варианта:

  • CREATE + INSERT — стандартный режим восстановления;
  • TRUNCATE + INSERT — меньше времени на создание таблиц;
  • REPLACE — восстанавливаем в рабочей базе старые данные, не затирая новые;
  • INSERT IGNORE — добавляем в базу удаленные или новые данные, не трогая существующие.

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

Интерфейс Dumper

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

Для работы Dumper понадобится классический L|WAMP-сервер, установка обычная для всех приложений, написанных на PHP (копируем файлы и устанавливаем права), и не будет сложной даже для новичка. Проект предоставляет подробную документацию и видеоуроки, демонстрирующие работу с Sypex Dumper.

Есть две редакции: Sypex Dumper (бесплатно) и Pro (10 долларов). Вторая имеет больше возможностей, все отличия приведены на сайте.

 

 

SQL Backup And FTP

Сайт: sqlbackupandftp.com

Лицензия:коммерческая, есть версия Free

Поддерживаемые СУБД:

MS SQL Server

MS SQL Server — одно из популярных решений, а потому встречается достаточно часто. Задание резервного копирования создается при помощи среды SQL Server Management Studio, собственно Transact-SQL и командлетов модуля SQL PowerShell (Backup-SqlDatabase). На сайте MS можно найти просто огромное количество документации, которая позволяет разобраться с процессом. Документация хотя и полная, но очень специфическая, а информация в интернете часто противоречит друг другу. Новичку действительно вначале потребуется потренироваться, «набив руку», поэтому, даже несмотря на все сказанное, сторонним разработчикам есть где развернуться. К тому же бесплатная версия SQL Server Express не может похвастаться встроенными инструментами для резервного копирования. Для более ранних версий MS SQL (до 2008) можно найти бесплатные утилиты, например SQL Server backup, но в большинстве подобные проекты уже коммерциализировались, хотя и предлагают всю функциональность часто за символическую сумму.

SQL Backup And FTP позволяет одним щелчком произвести бэкап MS SQL

Например, разработка SQL Backup And FTP и One-Click SQL Restore соответствует принципу «настроил и забыл». Обладая очень простым и понятным интерфейсом, они позволяют создавать копии баз данных MS SQL Server (включая Express) и Azure, сохранять зашифрованные и сжатые файлы на FTP и облачных сервисах (Dropbox, Box, Google Drive, MS SkyDrive или Amazon S3), результат можно тут же просмотреть. Возможен запуск процесса как вручную, так и по расписанию, отправка сообщения о результате задания по email, запуск пользовательских скриптов.

Поддерживаются все варианты бэкапа: полный, дифференциальный, журнал транзакций, копирование папки с файлами и многое другое. Старые резервные копии удаляются автоматически. Для подключения к виртуальному узлу используется SQL Management Studio, хотя здесь могут быть нюансы и это будет работать не во всех таких конфигурациях. Для загрузки предлагается пять версий — от бесплатной Free до навороченной Prof Lifetime (на момент написания этих строк стоила всего 149 долларов). Функционала Free вполне достаточно для небольших сетей, в которых установлено один-два SQL-сервера, все основные функции активны. Ограничено количество резервных БД, возможность отправки файлов на Google Drive и SkyDrive и шифрование файлов. Интерфейс хотя и не локализован, но очень прост и понятен даже новичку. Нужно лишь подключиться к SQL-серверу, после чего будет выведен список баз данных, следует отметить нужные, настроить доступ к удаленным ресурсам и указать время выполнения задания. И все это в одном окне.

Но есть одно «но». Сама программа не предназначена для восстановления архивов. Для этого предлагается отдельная бесплатная утилита One-Click SQL Restore, понимающая и формат, созданный командой BACKUP DATABASE. Админу необходимо лишь указать архив и сервер, на который восстановить данные, и нажать одну кнопку. Но в более сложных сценариях придется использовать RESTORE.

Утилита One-Click SQL Restore предназначена для восстановления баз MS SQL

 

Особенности бэкапа MS SQL Server

Создание резервной копии и восстановление СУБД имеет свои отличия, которые нужно учитывать, особенно их много при переносе архива на другой сервер. Для примера разберем некоторые нюансы MS SQL Server. Для архивирования при помощи Transact-SQL следует использовать команду BACKUP DATABASE (есть и разностная DIFFERENTIAL) и журнал транзакций BACKUP LOG.

Если резервная копия разворачивается на другом сервере, нужно убедиться, что присутствуют те же самые логические диски. Как вариант — можно вручную прописать правильные пути для файлов базы данных, используя опцию WITH MOVE команды RESTORE DATABASE.

Простая ситуация — бэкап и перенос баз на другие версии SQL Server. Эта операция поддерживается, но в случае SQL Server будет работать, если версия сервера, на которой разворачивается копия, такая же или новее, чем та, на которой она создавалась. Причем есть ограничение: новее не более чем на две версии. После восстановления БД будет находиться в режиме совместимости с той версией, с которой осуществлялся переход, то есть новые функции будут недоступны. Это легко поправить, изменив COMPATIBILITY_LEVEL. Можно это сделать при помощи GUI или SQL.

ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110;

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

 

Iperius

Сайт: iperiusbackup.com

Лицензия:коммерческая, есть версия Free

Поддерживаемые СУБД: Oracle 9–11, XE, MySQL, MariaDB, PostgreSQL и MS SQL Server

Когда приходится управлять несколькими типами СУБД, без комбайнов не обойтись. Выбор большой. Например, Iperius — легкая, очень простая в использовании и одновременная мощная программа для резервного копирования файлов, имеющая функцию горячего резервирования баз данных без прерывания в работе или блокирования. Обеспечивает полный или инкрементальный бэкап. Может создавать полные образы дисков для автоматической переустановки всей системы. Поддерживает резервное копирование на NAS, USB-устройства, стример, FTP/FTPS, Google Drive, Dropbox и SkyDrive. Поддерживает сжатие zip без ограничения в размере файлов и AES256-шифрование, запуск внешних скриптов и программ. Включает весьма функциональный планировщик заданий, возможно параллельное или последовательное выполнение нескольких заданий, результат отправляется на email. Поддерживаются многочисленные фильтры, переменные для персонализации путей и настроек.

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

Возможность закачки по FTP позволяет легко обновлять информацию на нескольких веб-сайтах. Открытые файлы резервируются при помощи технологии VSS (теневого копирования томов), что позволяет производить горячий бэкап не только файлов СУБД, но и других приложений. Для Oracle также задействуется средство организации резервного копирования и восстановления данных RMAN (Recovery Manager). Чтобы не перегружать канал, есть возможность настройки полосы пропускания. Управление резервированием и восстановлением производится при помощи локальной и веб-консоли. Все функции на виду, поэтому для настройки задания потребуется лишь понимание процесса, в документацию заглядывать даже не придется. Просто следуем подсказкам мастера. Также можно отметить менеджер учетных записей, что очень удобно при большом количестве систем.

Базовые функции предлагаются бесплатно, но возможность резервирования БД заложена только в версиях Advanced DB и Full. Поддерживается установка от XP до Windows Server 2012.

 

 

Handy Backup

Сайт: handybackup.ru

Лицензия:коммерческая

Поддерживаемые СУБД:Oracle, MySQL, IBM DB2 (7–9.5) и MS SQL Server

Одна из самых мощных систем управления реляционными базами данных — IBM DB2, имеющая уникальные функции по масштабированию и поддерживающая множество платформ. Поставляется в нескольких редакциях, которые построены на одной базе и отличаются функционально. Архитектура баз данных DB2 позволяет управлять практически всеми типами данных: документами, XML, медиафайлами и так далее. Особо популярна бесплатная DB2 Express-C. Бэкап очень прост:

db2 backup db sample

Или снапшот, использующий функцию Advanced Copy Services (ACS):

db2 backup db sample use snapshot

Но нужно помнить, что в случае снимков мы не можем восстанавливать (db2 recover db) отдельные таблицы. Есть и возможности по автоматическому бэкапу, и многое другое. Продукты хорошо документированы, хотя в русскоязычном интернете руководства встречаются редко. Также далеко не во всех специальных решениях можно найти поддержку DB2.

Например, Handy Backup позволяет выполнять бэкап нескольких типов серверов баз данных и сохранять файлы практически на любой носитель (жесткий диск, CD/DVD, облачное и сетевое хранилище, FTP/S, WebDAV и другие). Возможен бэкап баз данных через ODBC (только таблицы). Это одно из немногих решений, поддерживающих DB2, и к тому же имеет логотип «Ready for IBM DB2 Data Server Software». Вся процедура выполняется при помощи обычного мастера, в котором необходимо лишь выбрать нужный пункт и сформировать задачу. Сам процесс настройки настолько прост, что разобраться сможет и новичок. Можно создать несколько заданий, которые будут запускаться по расписанию. Результат фиксируется в журнале и отправляется по email. Во время работы задания остановка сервиса не требуется. Архив автоматически сжимается и шифруется, что гарантирует его безопасность.

Работа мастера создания нового задания в Handy Backup

Работу с DB2 поддерживают две версии Handy Backup — Office Expert (локальный) и Server Network (сетевой). Работает на компьютерах под управлением Win8/7/Vista/XP или 2012/2008/2003. Сам процесс развертывания несложен для любого админа.

 

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

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

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

Содержание статьи:

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

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

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

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

По умолчанию утилита будет выводить все в стандартный вывод, поэтому нам нужно перенаправить эти данные в файл, что мы и делаем с помощью оператора «>». Опции указывают параметры аутентификации и работы, а имя базы и таблицы — данные которые нужно экспортировать. Теперь рассмотрим кратко опции, которые будем использовать:

  • -A — копировать все таблицы из всех баз данных;
  • -i — записывать дополнительную информацию в комментариях;
  • -c — использовать имена колонок для инструкции INSERT;
  • -a — включать все возможные опции в инструкцию CREATE TABLE;
  • -k — отключает первичные ключи на время копирования;
  • -e — использовать многострочный вариант инструкции INSERT;
  • -f — продолжить даже после ошибки;
  • -h — имя хоста, на котором расположен сервер баз данных, по умолчанию localhost;
  • -n — не писать инструкции для создания базы данных;
  • -t — не писать инструкции для создания таблиц;
  • -d — не записывать данные таблиц, а только их структуру;
  • -p — пароль базы данных;
  • -P — порт сервера баз данных;
  • -Q — брать все имена таблиц, баз данных, полей в кавычки;
  • -X — использовать синтаксис XML вместо SQL;
  • -u — пользователь, от имени которого нужно подключаться к базе данных.

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

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

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

head -n 5 data-dump.sql

Но если во время создания копии возникнут какие-либо ошибки, они будут выведены на экран и вы сразу о них узнаете. Более сложный вариант, это выполнить резервное копирование mysql с другого хоста, если у вас есть к нему доступ:

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

Копирование таблицы mysql может быть выполнено простым добавлением имени таблицы в конец строки:

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

Также, чтобы выполнять автоматическое резервное копирование базы mysql может понадобиться сразу задать пароль, для этого указывайте его сразу после опции -p, без пробела:

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

Мы можем делать бэкап вручную время от времени, но это не совсем удобно, поскольку есть другие важные дела. Поэтому используем планировщик cron, чтобы автоматизировать процесс. Тут есть два способа более простой, и более сложный, но точный. Допустим, нам нужно создавать резервную копию каждый день, тогда просто создайте скрипт в папке /etc/cron.daily/ со следующим содержимым:

sudo vi /etc/cron.daily/mysql-backup

!/bin/bash
/usr/bin/mysqldump -u имя_пользователя -pпароль имя_базы > /backups/mysql-dump.sql

Папку /backups/mysql-dump.sql нужно заменить на свою папку для резервных копий. Осталось дать скрипту права на выполнение:

chmod ugo+x /etc/cron.daily/mysql-backup

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

sudo crontab -e

Добавьте в открывшейся файл такую строку и сохраните изменения:

30 2 * * * /usr/bin/mysqldump -u имя_пользователя -pпароль имя_базы > /backups/mysql-dump.sql

Команда будет выполняться каждый день, в 2:30, это удобно, поскольку ночью обычно меньше нагрузка на сервер. Как вы поняли, первое число — это минуты, второе — часы, третье день, дальше неделя и месяц. Звездочка значит, что этот параметр не имеет значения.

Восстановление из резервной копии

Восстановить резервную копию mysql или mariadb из существующего SQL файла тоже очень просто. Поскольку использовался синтаксис sql мы просто можем выполнить все команды с помощью стандартного клиента mysql.

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

mysql -u root -p

Затем создайте новую базу данных, например, с именем new_database, если база данных уже существует, то этого делать не нужно:

mysql> CREATE DATABASE new_database;

Дальше закройте оболочку, нажав сочетание клавиш Ctrl+Q и импортируйте данные из файла командой:

mysql -u пользователь -p база_данных < data-dump.sql

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

Выводы

Теперь вы знаете как выполняется копирование базы данных mysql, а также как восстановить скопированную информацию. Мы рассмотрели все возможные опции mysqldump чтобы вы могли настроить утилиту так, как вам нужно. Резервное копирование базы данных mysql это очень важный момент и в определенной ситуации может сохранить много времени, поэтому обязательно настройте у себя на сервере!

12 типичных ошибок при бэкапе баз данных / Хабр


Изначально эта статья задумывалась только для разработчиков и администраторов СУБД Firebird, но после общения с администраторами других БД выяснилось, что большинство ошибок общие, и на очень похожие грабли наступают буквально все. Если Вы можете что-то добавить к этому списку (пусть даже специфическое для конкретной СУБД), пишите в личную почту или в комментариях.
In English: 12 Common Mistakes while Backing Up Databases

Наша компания занимается инструментами восстановления, резервного копирования, оптимизации и поддержкой СУБД (в основном Firebird, но есть и MSSQL, PostgreSQL, InterBase и др.) и, как результат многочисленных аудитов и ремонтов, накопила коллекцию ошибок, связанных с резервным копированием. Все пункты ниже изложены по мотивам реальных случаев с повреждением баз, потерей и повреждением бэкапов, дисков, сбоями серверов, и прочих «радостей» администраторов БД.

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

Итак, приступим.

1. Удаление предыдущей копии бэкапа до того, как будет создана новая копия бэкапа
Чаще всего эту ошибку совершают новички, которые не понимают, что основная цель существования резервной копии БД – обеспечить минимальный простой информационной системы (важной частью которой является БД), а не просто создание копии БД.
В результате, с момента удаления последнего бэкапа до создания нового, система находится в незащищенном состоянии, потому что в этот период у базы данных нет ни одной резервной копии. Так как бэкап может создаваться достаточно долго, то это идеальное время для срабатывания закона Мерфи. Особенно хорошо этот подход работает в связке с пунктом 7 (см. ниже).
Рекомендация: не удаляйте предыдущий бэкап до того момента, как создан новый! (и не делайте новый бэкап в уже существующий файл)

2. Перезапись существующей базы данных при восстановлении из бэкапа
Эту ошибку совершают реже, но вот результаты могут быть гораздо печальнее. Если бэкап не проверялся и был поврежден (см. пункт 6), то в результате перезаписи у вас не будет ни предыдущей копии базы, ни валидного бэкапа.
Обычно это безобразие случается в пятницу вечером, в момент дерготни, неразберихи и противоречивых указаний со стороны начальства. Немного отрицательного везения и томные выходные в серверной обеспечены.
У Firebird есть некая защита от этой ошибки – создание рестора из бэкапа с помощью утилиты gbak с дефолтным ключом –create не сработает в случае, если указанное имя файла указывает на существующую БД. К сожалению, есть и обход этой защиты – переключатель –rep, который позволяет-таки переписать существующий файл.
Рекомендации: никогда не перезаписывайте файл боевой БД, не получив письменного указания руководства и, желательно, не получив предложения о новой работе.

3. Использование одношагового бэкапа-рестора, без создания промежуточного файла бэкапа
Стандартные потоки ввода-вывода позволяют провернуть с многими СУБД (с Firebird в том числе) интересный трюк: выполнять потоковый бэкап с немедленным восстановлением БД из него. В результате не создается промежуточный файл бэкапа. Это удобно для проведения регламентных работ и запуска проверочного восстановления (при наличии другой резервной копии), но ни в коем случае не надо использовать это для автоматического бэкапа!
Если в процессе такого бэкап-рестора произойдет серьёзный сбой диска, например, то может повредиться исходная база данных, а новая еще не будет создана. Конечно, если п.1 соблюдается, и есть копия БД от предыдущей попытки, то произойдет только потеря данных, которые были созданы или изменены в БД с момента создания ее копии.
Рекомендации: не используйте одношаговый бэкап-рестор в автоматическом режиме, а в ручном всегда проверяйте наличие достаточно свежей копии.

4. Хранение бэкапа и базы данных на одном и том же физическом устройстве
Тут многие могут посмеяться, что советы мы какие-то детские даем – это же азбука системного администрирования. Так-то оно так, но в связи с распространением виртуальных сред и БД, и диск могут находиться на одной СХД. А она обязательно сломается в самый неподходящий для бизнеса момент. Плюс, все еще существуют люди, которые верят в то, что если они используют RAID (от 1 и выше), то с их данными вообще ничего не может случиться. Еще есть люди, которые верят в сверхнадежность «брендового» железа, но это особый случай.
Рекомендации: не храните бэкап и БД на одном и том же физическом устройстве, каким бы надежным оно не казалась.

5. Отсутствие проверки успешного окончания бэкапа
Вот это довольно частая ошибка и администраторов, и руководителей ИТ подразделений. Если результат бэкапа не проверять, то можно бэкап не делать вообще — результат в общем тот же. Обязательно нужны нотификации по email об успешном бэкапе, а еще лучше и по СМС. Причем, отсутствие нотификации это признак проблемы!
А причем тут руководители, спросит внимательный читатель, дочитавший до этого места? А притом, что администратор обычно бэкап настроит, но вот нотификации ему проверять лень, тем более что лежат они у него в отдельной папочке, и поэтому руководителю ИТ-отдела надо периодически запрашивать дополнительный отчет о состоянии всех бэкапов. Это к вопросу, кого наказывать, если бэкапы вроде есть, но в нужный момент их не оказалось 🙂
! А при комбинировании с пунктом 2 получаем отсутствие и базы, и бэкапа.
Рекомендации: использовать инструменты автоматизации бэкапов, которые умеют отслеживать успешные и неуспешные бэкапы, сообщать пользователям о проблемах, и имеют обзорные средства контроля (особенно актуально, когда нужно контролировать десятки и сотни бэкапов на разных серверах).

6. Отсутствие валидации бэкапов
То, что бэкапы куда-то кладутся, не означает, что они оттуда могут быть прочитаны.
Поэтому обязательна периодическая верификация создаваемых бэкапов, чтобы быть уверенным, что создаваемые бэкапы не повреждены, не были скопированы в /dev/null
Рекомендации: никому не доверять, даже себе. Всех надо проверять.

7. Отсутствие health check базы данных при использовании неверифицированных бэкапов
Обычно СУБД имеют несколько видов бэкапа – дампы, просто бэкапы и т.д. Не вдаваясь в конкретику, можно выделить 2 категории – верифицированные и неверифицированные бэкапы. У Firebird это gbak и nbackup.
Gbak читает всю БД на уровне записей для создания файла бэкапа, и создает БД путем вставки записей в новую БД, и таким образом верифицирует и бэкап (есть варианты, как ошибки могут просочиться в отресторенную копию, но это уже другой вид факапа администратора БД, связанный с неверной миграцией), и саму базы данных (если она может быть прочитана от начала до конца, то с большой долей вероятности она не повреждена).
Nbackup (он же инкрементальный бэкап) – временно блокирует основной файл БД на запись (в консистентном состоянии), и позволяет быстро скопировать файл базы данных (полностью или частично/инкрементально).
Для больших БД Firebird (более 500Гб), предпочтительно делать nbackup, чтобы не тормозить работу пользователей, но при этом нужно проверять БД, ведь созданные неверифицированные бэкапы – это страничные копии БД, и если ошибка гнездится на уровне записей (такое случается из-за сбоя RAM) или на логическом уровне, то неверифицированный бэкап будет ее содержать так же, как и оригинальная БД.
Для этого нужно использовать онлайн-валидацию исходной базы данных (в Firebird начиная с версии 2.5.4 доступна онлайн-валидация при помощи gfix, а наш инструмент FBDataGuard поддерживает онлайн-проверку БД для версий 1.5-2.5).
Также, в дополнение к неверифицированному бэкапу желательно периодически (раз в неделю, например) делать верифицированный бэкап.
Для других СУБД необходимо использовать соответствующие средства и комбинации проверок.

8. Отсутствие контроля за свободным местом для бэкапа
В общем-то, это классическая ошибка — при недостатке места бэкап занимает все свободное место и аварийно завершается. При размещении бэкапа на одном диске вместе с БД может привести к остановке работы с БД, при размещении на системном диске – к поломке системы.
В комбинации с пунктом 4 в лучшем случае получим остановку работы системы, потому что базе данных тоже нужно свободное место, а оно кончилось из-за бэкапа.
А в комбинации с пунктами 5 и 2 опять получаем в результате отсутствие и базы, и бэкапа.
Рекомендации: использовать инструменты для бэкапа, которые делают прогноз размера бэкапа и предупреждают о возможной нехватке места.

9. Отсутствие контроля времени продолжительности бэкапа
Буквально полгода назад бэкап длился 40 минут, и вдруг стал 3 часа – почему? Возможно, вырос размер БД, а может быть, выпал диск из RAID-массива, отчего скорость записи резко деградировала, и все ваши бэкапы вот-вот покинут этот бренный мир. А может быть, добрый коллега одновременно включил еще одну систему резервного копирования (кстати, в Firebird можно запустить несколько бэкапов сразу, только не очень понятно, зачем это может быть нужно).
Если не контролировать время исполнения бэкапа, то можно проглядеть возникшую проблему и упустить шанс исправить ее до того, как она станет большой.
Также, в случае, если система резервного копирования не отслеживает состояния заданий, а запускает их просто по графику, легко можно попасть на «утренний троллейбус» — это когда новый бэкап может начаться в момент, пока предыдущий еще не закончился.
Рекомендации: использовать средства контроля продолжительности процесса бэкапа.

10. Исполнение бэкапа БД во время применения апдейтов ОС
Очень частая проблема, особенно в комбинации с п.9 и включенными автоматическими апдейтами Windows (которые по умолчанию происходят в 3 ночи). В лучшем случае приводит к замедлению процесса, а если ОС перегружается для применения апдейтов, то бэкап будет испорчен. Хорошо еще, что апдейты ОС не каждый день случаются.
Рекомендации: Если нельзя отключить, то назначьте апдейты ОС на такое время, когда они не смогут помешать бэкапам.

11. Бэкап базы данных средствами файлового бэкапа или средствами бэкапа виртуальной машины целиком, при включенном сервере БД
Многие администраторы забывают о том факте, что любая СУБД имеет активный и сложный кэш, в котором содержатся читаемые и записываемые данные, а сами файлы БД открываются в режиме случайного доступа.
Именно поэтому необходимо использовать специальные виды бэкапа, а не простой файловый бэкап (включая простое копирование файлов БД) или бэкап виртуальной машины. Файловые средства бэкапа читают БД последовательно и, особенно для больших БД, могут идти продолжительное время, поэтому нельзя гарантировать целостность созданной копии.
Для желающих осуществлять бэкап БД с помощью файловых средств или средств бэкапа виртуальных машин можно предложить 2 способа:

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

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

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

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

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

Выводы
Правильно организовать резервное копирование для вашей любимой СУБД не так-то и просто, поэтому обычно администраторы БД из организаций, где ценят данные, обычно используют профессиональные инструменты для бэкапов, которые позволяют учесть и предотвратить описанные выше ошибки. Для Firebird (уж простите за рекламу) есть наш FBDataGuard, для других СУБД можно использовать DBArtisan или другие средства.

Ну, и конечно – не забывайте холить и лелеять свою админскую паранойю, например, возьмите и проверьте свои бэкапы… вот прямо сейчас!

UPDATE

Господа, просьба откликнуться в личку тех, кто использует CBT на VMWare для ВМ с БД.

Всё что вы стеснялись спросить о бэкапах Microsoft SQL Server / ХабрВ ходе проведения презентаций о бэкапах и восстановлении баз данных SQL Server, обычно задаются два типа вопросов. Первые задаются прямо по ходу презентации из зала, вторые задаются уже после, в приватной беседе. Эти, «приватные» вопросы, зачастую более интересны и я попробую дать ответы на наиболее сложные и интересные из них, вместо того чтобы писать ещё одну статью о том как вы должны делать бэкапы, или почему вы должны делать бэкапы, или даже почему вы должны проверять свои бэкапы (но вы и вправду должны проверять свои бэкапы).

Могу ли я развернуть бэкап на версии SQL Server, отличной от той, на которой был сделан бэкап? Какие проблемы могут возникнуть?

Вы можете восстановить бэкап на другой версии SQL Server, но только в том случае, если версия SQL Server, на которой вы разворачиваете бэкап, более новая чем та, на которой вы его сделали. Другими словами, вы можете развернуть бэкап, сделанный SQL Server 2000 на SQL Server 2005, SQL Server 2005 на SQL Server 2008 R2 или с SQL Server 2008 на SQL Server 2012, но никогда не сможете сделать этого в обратном направлении. Каждая версия SQL Server вносит свои изменения в базу данных и файлы, хранящие её. Компания Microsoft не будет «возвращаться в прошлое» и переписывать предыдущие версии SQL Server для поддержки этих изменений. Если же вам действительно нужно перейти на более старую версию SQL Server, вам нужно будет заскриптовать схему и сами данные (например, вот статья, посвящённая подобному переходу)

Для того, чтобы определить на какой версии SQL Server был создан бэкап, нужно посмотреть заголовок файла бэкапа:

RESTORE HEADERONLY FROM DISK = 'd:\bu\mm.bak';

В результате вы увидите Major, Minor и Build-версии того экземпляра SQL Server, на котором был сделан бэкап (как показано на скриншоте снизу). Это позволит вам определить подходящую версию SQL Server для восстановления этого бэкапа.

При восстановлении БД на более новую версию SQL Server, может оказаться, что в ней присутствует что-то несовместимое с этой версией SQL Server. Наиболее безопасным подходом к переходу на новую версию SQL Server будет запуск Microsoft Upgrade Advisor (бесплатная утилита доступная для каждой версии SQL Server) на базе, которую требуется переносить, убедиться, что она готова, а затем сделать бэкап и восстановить её на новом экземпляре (но только в этом порядке, а не сначала попытаться перенести бэкап, а затем запустить помощника).

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

ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110;

Различные числа обозначают различные версии SQL Server: 90 для SQL Server 2005, 100 для SQL Server 2008 и 2008 R2 и 110 для SQL Server 2012 (более подробно о версиях SQL Server можно прочитать здесь — прим. переводчика).

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

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

Да, вы можете это сделать. Если вы разворачиваете бэкап на другом сервере, то нужно убедиться в том, что на новом сервере у вас присутствуют те же самые логические диски, что и на «старом» сервере, либо вручную прописать правильные пути для файлов базы данных, используя опцию WITH MOVE команды RESTORE DATABASE:
RESTORE DATABASE NewDBName
FROM  DISK = 'c:\bu\mm.bak'
WITH  MOVE 'OldDB' TO 'c:\data\new_mm.mdf',
MOVE 'OldDB_Log' TO 'c:\data\new_mm_log.ldf';

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

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

Когда вы восстанавливаете БД на новом сервере, вы можете столкнуться с проблемой «Orphaned Users» (пользователей, утративших связь с учётной записью, согласно переводу на msdn – прим. переводчика), если пользователь базы данных связан с учётной записью, не представленной на новом сервере. Вам нужно будет исправить эту ошибку.

Можно ли присоединять как базу данных файл MDF, если у меня нет файла журнала транзакций?

Единственный вариант, когда это допустимо – если журнал транзакций был утерян уже после того как работа базы данных была корректно завершена. В любом случае – это не очень хорошая идея. При присоединении БД, файл журнала транзакций, так же как и файл данных, нужен для проведения процесса восстановления БД (здесь под восстановлением БД понимается не операция RESTORE DATABASE, а recovery – процесс, происходящий при каждом запуске SQL Server, при котором SQL Server «проходит» по журналу транзакций и приводит файлы данных в согласованное состояние – прим. переводчика). Тем не менее, в некоторых случаях возможно присоединение файла данных без файла журнала транзакций, но эта возможность предназначена только для тех случаев, когда файл журнала транзакций был повреждён или потерян в результате проблем с оборудованием и при отсутствии резервных копий. Конечно, база данных не может существовать без журнала транзакций, и при присоединении БД без файла журнала транзакций, SQL Server просто пересоздаст его.

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

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

Моя БД лежит на SAN. Я слышал, что бэкапов SAN достаточно. Это правда?

Это может быть правдой. Главное чтобы ваша SAN (СХД, Сеть/Система Хранения Данных – прим. переводчика) поддерживала транзакции SQL Server. Если это так, тогда она будет знать о том, что в БД существуют транзакции и наличие этих транзакций может означать, что данные в файлах данных, могут быть не полными, поскольку процесс записи данных, изменённых в этих транзакциях, на жёсткий диск, может быть не завершён на момент создания резервной копии. Те бэкапы, которые делает сам SQL Server, естественно, учитывают эти моменты.

EMC Data Domain, например – это комбинация ПО и SAN, обеспечивающая поддержку транзакций, как и продукция других вендоров, но вам всё равно нужно проверить документацию вашего SAN. Обратите внимание на наличие фраз вроде «transaction consistency», или «transaction aware», или чего-то подобного. Если вы их не нашли, то я бы посоветовал вам проверить восстановление БД прежде чем вы решите, что бэкапов SAN вам достаточно для выполнения всех ваших требований к резервным копиям. Впрочем, даже после того, как вы убедились, что бэкапы SAN выполняются корректно, это вовсе не означает, что «родные» бэкапы SQL Server вам больше не нужны. Если вам нужна возможность восстановления вашей БД на момент времени, например, вам всё равно придётся делать бэкапы журнала транзакций средствами SQL Server.

Обычно, при создании бэкапа, SAN с поддержкой SQL Server, использует VDI-интерфейс SQL Server и «замораживает» БД на время создания резервной копии. Если вы запустите механизм создания такого бэкапа и посмотрите в журнал ошибок SQL Server, там вы увидите сообщения о том, что операции IO были заморожены.

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

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

SQL Server не является обычным десктопным приложением. Он управляет своими файлами таким образом, чтобы обеспечить выполнение всех свойств ACID (Atomic, Consistency, Isolated, Durable – чуть более подробно — прим. переводчика). Вкратце, чтобы обеспечить успешное завершение транзакций, SQL Server старается никому не давать доступ к своим файлам и сам модифицирует их так, как ему нужно.

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

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

Намного безопаснее и проще использовать встроенный механизм SQL Server
для создания бэкапов. Такой бэкап будет являться полной копией вашей БД, и все свойства ACID будут выполнены.

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

Вы можете использовать что-нибудь вроде SQLCMD и выгрузить таблицы в простой текстовый файл, но потом, вместо того, чтобы просто одной командой восстановить БД, вам придётся выполнить целый ряд команд. Во-первых, вам нужно будет создать пустую БД. Затем, вам нужно будет создать и загрузить из файла каждую таблицу. Если какая-нибудь таблица содержит столбец IDENTITY, вам нужно будет выполнять SET IDENTITY_INSERT на каждой из этих таблиц. Так же, вам придётся тщательно определять порядок, в котором вы будете загружать данные в таблицы, чтобы обеспечивать целостность.

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

Конечно, вы вправе поступать таким образом. С другой стороны, вы можете просто выполнить команду BACKUP DATABASE, а потом, когда понадобится, восстановить этот бэкап.

Зачем платить деньги за утилиты, делающие бэкапы, если SQL Server сам умеет это делать?

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

Бэкапы, создаваемые самим SQL Server, работают отлично, но вам нужно проделать немало работы для того, чтобы их настроить и ещё больше для того, чтобы их автоматизировать. Хорошая сторонняя утилита сделает процесс автоматизации очень простым. Более того, с её помощью вы сможете автоматизировать другие процессы связанные с бэкапами, такие как зеркалирование/доставка журналов и проверка целостности бэкапа.

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

Если бэкап лежит на сетевой шаре, может ли кто-то прочитать его?

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

Более того, из бэкапа можно достать схему БД или данные, даже не восстанавливая его. Если у вас есть утилита SQL Data Compare, то она, запущенная с ключом /Export сможет вытащить все данные из бэкапа в CSV-формате, сравнивая этот бэкап с пустой БД и не спрашивая никакого пароля. Так же, та же самая SQL Data Compare сможет создать для вас скрипт создающий схему БД.

Для того чтобы предотвратить несанкционированный доступ к бэкапу, вам придётся сделать несколько вещей. Во-первых, убедиться, что шара, на которой хранятся бэкапы, доступна ограниченному кругу лиц. Во-вторых, вы должны хранить только те бэкапы, которые вам действительно нужны. Наконец, если вы используете сторонние утилиты для создания резервных копий (типа SQL Backup Pro), вы можете зашифровать бэкап, так что если кто-то и получит доступ непосредственно к файлу, то прочитать оттуда ничего не сможет.

Без сторонних утилит, вы сможете этого добиться, используя Transparent Data Encryption (TDE).

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

А кто-нибудь может изменить содержимое резервной копии?

Возможности изменять содержимое файла резервной копии не предусмотрено. Поскольку бэкап это постраничная копия базы данных (в том виде в котором она существовала на момент создания бэкапа), восстановленная копия этой БД будет находиться в абсолютно том же состоянии, в котором оригинал был на момент создания бэкапа.
Когда SQL Server считывает каждую страницу, в ходе восстановления БД, он высчитывает её контрольную сумму, зависящую от её содержания, и сравнивает с тем значением, которое было прочитано с оригинальной страницы в момент создания бэкапа (подразумевается, что вы использовали параметр WITH CHECKSUM при создании резервной копии). Если кто-либо производил изменения в файле резервной копии, эти значения не совпадут и SQL Server отметит такую страницу как повреждённую.
Существует ли какой-либо флаг, установив который при создании бэкапа, я могу быть уверен, что всегда смогу из него восстановиться?

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

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

RESTORE VERIFYONLY
FROM DISK= '<Backup_location>'

Вторая проверка возможно только в том случае, если вы запускали процедуру создания резервной копии с параметром WITH CHECKSUM. Это означает, что в ходе создания резервной копии, SQL Server пересчитывает и сверяет контрольные суммы для всех прочитанных страниц. Если он наткнётся на страницу, для которой эти суммы не сойдутся, операция создания резервной копии завершится с ошибкой. Если проверка завершается успешно, BACKUP WITH CHECKSUM вычислит и запишет контрольную сумму созданной копии.

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

RESTORE VERIFYONLY
FROM DISK= '<Backup_location>'
WITH CHECKSUM

Проблемы могут возникнуть в двух местах. Во первых, проверка заголовка в ходе выполнения VERIFYONLY не проверяет всё что может повлиять на процесс восстановления. Это означает, что RESTORE VERIFYONLY может завершиться без ошибок, но БД всё равно не сможет быть восстановлена из «проверенной» копии.

Во-вторых, CHECKSUM не может обнаружить повреждения, произошедшие в памяти. Если страница данных была обновлена, находясь в памяти и затем произошло её повреждение прежде чем она была записана на диск (и, соответственно, в бэкап), тогда вычисление контрольной суммы не покажет никакой ошибки, а просто подтвердит, что в бэкап была записана та же страница, что и содержалась в БД в момент создания бэкапа. Т.е. если страница уже была повреждена в момент создания бэкапа, ошибка не может быть найдена с помощью контрольной суммы и восстановление из этого бэкапа может завершиться ошибкой.

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

Не содержит ли бэкап что-нибудь кроме данных? Может ли кто-нибудь прочесть пароли из него?

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

Однако, в автономных базах данных (contained databases — прим. переводчика) существует понятие USER WITH PASSWORD, поскольку сама идея автономных баз данных предполагает минимальную связь такой базы с сервером. В этом случае, пароль будет находиться в бэкапе, что может привести к попыткам достать его оттуда. Пароли хранятся не открытым текстом, они хэшируются, точно так же как пароли учётных записей (которые хранятся в системной базе данных master и, естественно, попадают в её бэкап).

Microsoft предлагает несколько best practices по безопасности автономных баз данных.

Зачем в бэкапе индексы, статистика и остальные штуки, которые легко пересоздать? Это же просто потеря времени?

А по-моему, потеря времени – это попытки разделить вещи таким образом и делать резервную копию только одной части. Во-первых, как это сделать? Например, как забэкапить данные, не делая, при этом, бэкапа кластерных индексов? Это невозможно, поскольку листовой уровень кластерного индекса – это страницы данных. Т.е., можно сказать, что кластерные индексы – это сами таблицы, поэтому кластерные индексы должны быть включены в бэкап. Конечно, возможно выделить некластерные индексы в отдельную файловую группу и не делать её бэкап, но потом, после восстановления того бэкапа, что у нас есть, нам всё равно нужно будет возвращать эту файловую группу к жизни и перестраивать все индексы. Так чего мы добьёмся?

Со статистикой так же возникнут проблемы. SQL Server бэкапит статистику вместе с базой данных (и она занимает очень мало места, поскольку, гистограмма, называющаяся статистикой, строится всего лишь по 200 строкам) и восстанавливает её вместе с БД. Однако, если после восстановления мы начнём пересоздавать индексы, поскольку не делали их резервной копии, нам придётся пересоздавать и статистику. Это так же потребует дополнительного времени, а база данных, тем временем, будет оставаться недоступной.

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

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

ОМГ! Я только что удалил таблицу! Я знаю, что это есть в журнале транзакций. Как мне её вернуть?

После того как транзакция была зафиксирована, SQL Server не сможет её откатить. Операции DELETE И TRUNCATE удаляют данные совершенно разными способами. Операция DELETE удаляет данные с помощью транзакций, удаляющих каждую строку. Операция TRUNCATE просто отмечает странницы данных, на которых лежали удаляемые данные, как не использующиеся. Но последствия ни одной из этих операций не могут быть устранены вручную при просмотре журнала транзакций. Вместо этого, вам нужно выполнить процесс, называющийся восстановлением на момент времени. Вы должны немедленно сделать бэкап журнала транзакций вашей БД для того, чтобы сохранить все изменения сделанные до того момента, как вы случайно удалили нужные данные из таблицы. Затем, вам нужно выполнить шаги, описанные в главе 6 этой книги для восстановления на момент времени (в MSDN тоже всё есть – прим. переводчика).

Другой вариант – использование сторонних утилит, типа SQL Backup Pro, которые могут выполнять восстановление отдельных объектов БД в режиме online из имеющихся резервных копий.

А если я просто хочу создать с помощью бэкапа скрипт для построения БД, без восстановления непосредственно бэкапа…?

Стандартных средств для создания такого скрипта в SQL Server не предусмотрено. Однако, утилиты, типа SQL Compare, могут сформировать его. Он легко создаётся с помощью GUI, но так же это возможно с использованием PowerShell:

& 'C:\Program Files (x86)\Red Gate\SQL Compare 8\SQLCompare.exe' /Backup1:C:\MyBackups\MyBackupFile.bak /MakeScripts:"C:\MyScripts\MyBackupScript"

Так же, вы можете обратить внимание на SQL Virtual Restore. Эта утилита позволяет вам примонтировать бэкап к вашему SQL Server так, как будто бы вы запускали процесс восстановления из этого бэкапа, но не требует использования всего того места, которое было бы необходимым при восстановлени. Примонтированный таким образом бэкап выглядит как самая обычная база данных и вы можете заскриптовать её любым удобным вам образом.

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

Полный и инкрементный бэкап Mysql

Хочу поделиться с вами информацией на очень актуальную и востребованную тему, связанную с базами данных. Я расскажу, как можно на лету делать полные и инкрементные бэкапы баз данных mysql с помощью Percona XtraBackup. Какой-то уникальной информации не будет. Я просто поделюсь своими методами и подходами к архивированию небольших и средних баз данных.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Администратор Linux» в OTUS. Курс не для новичков, для поступления нужно пройти .

Введение

В качестве примера я рассмотрю серверы с установленными там продуктами bitrix, работающими в bitrixenv. Особенностью будет то, что bitrix до сих пор использует не самую свежую версию mysql от percona — Percona Server for MySQL 5.7. Тем не менее, проблем с этим нет никаких. Версия будет поддерживаться минимум до октября 2023 года.

Для полных и инкрементных бэкапов я рассмотрю утилиту Percona XtraBackup, которая позволяет делать архивы баз данных на лету без блокировок таблиц. В моей статье будет использоваться версия 2.4, так как именно она поддерживает mysql 5.7. Это максимально доступная версия в репозиториях, которые устанавливает окружение bitrixenv.

Примеры в этой статье будут актуальны практически для всех версий Mysql и XtraBackup, так как в подходах и командах отличий почти нет. Важно знать, что последняя версия XtraBackup на момент написания статьи была 8.0 и она поддерживает популярный форк mysql — MariaDB только до версии 10.2 включительно, да и то с оговорками. Для более поздних версий mariadb рекомендуется использовать mariabackup. Это форк XtraBackup, который в использовании практически ничем не отличается от оригинала.

Сегодня я рассмотрю инкрементные бэкапы mysql только с помощью XtraBackup, а так же полные бэкапы в том числе с помощью mysqldump. MariaDB и Mariabackup рассматривать не буду. Принципиальных отличий между ними нет. Там все то же самое.

Установка Percona XtraBackup

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

# yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

Дальше ставим нужную нам версию программы. Самую последнюю 8.0:

# yum install percona-xtrabackup-80

или 2.4

# yum install percona-xtrabackup-24

Обращаю внимание, что если на сервере с установленным bitrixenv установить просто пакет xtrabackup, без указания версии, будет установлена версия 2.3, которая не работает с уставленным там же по дефолту сервером mysql 5.7.

Устанавливаем в Debian/Ubuntu:

# wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb
# dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb

И сам пакет:

# apt update && apt install percona-xtrabackup-80

Полный бэкап Mysql сервера

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

# xtrabackup – backup – user=root – password='R(zDXcVUmI[zwx%aNBTN' – target-dir=/root/backupdb/full

Полный бэкап mysqlПолный бэкап mysql

backup инициируем процедуру бэкапа
user=root пользователь mysql
password=’R(zDXcVUmI[zwx%aNBTN’ пароль пользователя, взятый в одинарные кавычки
target-dir=/root/backupdb/full директория для создания полного бэкапа mysql

В дальнейших примерах я не буду указывать пользователя и пароль, чтобы упростить команды. Эти данные я указал в файле ~/.my.cnf.

[client]
user=root
password='R(zDXcVUmI[zwx%aNBTN'

Мы сделали полный архив всего mysql сервера. В таком виде данные не консистентны, так как они могли меняться во время архивации. Если восстановить их как есть, сервер mysql не запустится. Будет ругаться на поврежденные данные. Чтобы восстановить целостность данных, необходимо выполнить еще одну команду.

# xtrabackup – prepare – target-dir=/root/backupdb/full

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

# xtrabackup – backup – compress – target-dir=/root/backupdb/full

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

# xtrabackup – decompress – target-dir=/root/backupdb/full

Для того, чтобы команда decompress отработала без ошибки:

sh: qpress: command not found
cat: write error: Broken pipe
Error: decrypt and decompress thread 0 failed.

Необходимо установить пакет qpress.

# yum install qpress

Он есть в репозитории percona. После этого распаковка пройдет штатно.

Сжатый архив mysqlСжатый архив mysql

Лично я не вижу большого смысла использовать ключи compress и decompress. Можно сделать полный бэкап, подготовить его, а потом сжать тем же gzip.

# tar -czvf /root/backupdb/full.tar.gz -C /root/backupdb full

На выходе получите тот же архив, только сжат лучше и нет необходимости ставить дополнительный софт. Gzip и tar обычно есть во всех дистрибутивах. К тому же архив в виде единого файла проще и быстрее передать на сервер бэкапов и там хранить.

В завершении раздела про полный backup, предлагаю простенький скрипт для автоматизации процесса через cron — mysql-full-backup.sh.

#!/bin/bash

DATA=`date +%Y-%m-%d`

mkdir -p /root/backupdb/$DATA
xtrabackup – backup – target-dir=/root/backupdb/$DATA/full
xtrabackup – prepare – target-dir=/root/backupdb/$DATA/full
tar -czvf /root/backupdb/$DATA/full.tar.gz -C /root/backupdb/$DATA full
rm -rf /root/backupdb/$DATA/full

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

Инкрементный бэкап Mysql

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

# xtrabackup – backup – target-dir=/root/backupdb/inc1 – incremental-basedir=/root/backupdb/full

Инкрементный бэкап mysqlИнкрементный бэкап mysql

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

backup_type = full-backuped
from_lsn = 0
to_lsn = 17687056
last_lsn = 17687065
compact = 0
recover_binlog_info = 1
flushed_lsn = 17687065

LSN — log sequence number. Это регистрационные номера транзакций. В данном случае полный бэкап начинается с нулевой транзакции и заканчивается 17687056. Теперь смотрим этот же файл в директории inc1.

backup_type = incremental
from_lsn = 17687056
to_lsn = 17710039
last_lsn = 17710048
compact = 0
recover_binlog_info = 1
flushed_lsn = 17710048

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

# xtrabackup – backup – target-dir=/root/backupdb/inc2 – incremental-basedir=/root/backupdb/full

либо так:

# xtrabackup – backup – target-dir=/root/backupdb/inc2 – incremental-basedir=/root/backupdb/inc1

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

Предлагаю вот такой скрипт для инкрементных бэкапов — mysql-inc-backup.sh.

#!/bin/bash

DATA1=`date +%Y-%m-%d`
DATA2=`date +%H-%M-%S`

xtrabackup – backup – target-dir=/root/backupdb/$DATA1/inc-$DATA2 – incremental-basedir=/root/backupdb/$DATA1/full

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

Структура архивовСтруктура архивов

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

Восстановление из бэкапа

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

# systemctl stop mysqld && rm -rf /var/lib/mysql/*
# xtrabackup – copy-back – target-dir=/root/backupdb/full
# chown -R mysql:mysql /var/lib/mysql
# systemctl start mysqld

Разбираем, что я сделал.

  1. Остановил mysql сервер и удалил все из ее рабочей директории.
  2. Восстановил данные из архивной копии xtrabackup. По факту он просто скопировал данные в рабочую директорию mysql сервера.
  3. Назначил пользователя mysql владельцем рабочей директории и всего ее содержимого.
  4. Запустил mysql сервер с восстановленными данными.

После запуска mysql сервера проверяйте лог /var/log/mysql/error.log на предмет ошибок. Если увидите там такие ошибки:

[ERROR] InnoDB: Page [page id: space=14, page number=4] log sequence number 17744745 is in the future! Current system log sequence number 9160744.

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

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

# yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

Ставим mysql server и xtrabackup нужной версии.

# yum install Percona-Server-server-57 percona-xtrabackup-24

Копируем на новый сервер архив сервера баз данных.

# scp [email protected]:/root/backupdb/full.tar.gz ~

Распаковываем его:

# tar xzvf full.tar.gz

Восстанавливаем данные и запускаем mysql сервер.

# xtrabackup – copy-back – target-dir=~/full
# chown -R mysql:mysql /var/lib/mysql
# systemctl start mysqld

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

# mysql -u root -p
mysql> show databases;
mysql> SELECT user,authentication_string,plugin,host FROM mysql.user;

Восстановление mysql баз из бэкапаВосстановление mysql баз из бэкапа

Все на месте, как и на исходном сервере.

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

# xtrabackup – prepare – apply-log-only – target-dir=/root/backupdb/full

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

# xtrabackup – prepare – apply-log-only – target-dir=/root/backupdb/full – incremental-dir=/root/backupdb/inc1

И так для всех остальных инкрементных копий, если у вас из них выстроена цепочка. Контролировать состояние полного архива и сопоставлять с инкрементами можно по содержимому файлов xtrabackup_checkpoints. После того, как восстановили все инкрементные архивы, на последнем из них не нужно использовать ключ apply-log-only. Так же он не нужен, если у вас только одна инкрементная копия. Завершающий этап подготовки полной копии должен быть без него.

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

Бэкап отдельной таблицы или базы

Не всегда нужны архивные копии всего mysql сервера. Иногда достаточно отдельной базы данных или даже таблицы. Xtrabackup позволяет это сделать. Архивируем только одну базу данных sitemanager.

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

# xtrabackup – backup – databases "sitemanager" – target-dir=/root/backupdb/sitemanager

Восстановление отдельной базы mysql будет выглядеть так.

# xtrabackup – prepare – databases "sitemanager" – target-dir=/root/backupdb/sitemanager
# systemctl stop mysqld
# mkdir -p /var/lib/mysql.old/sitemanager
# mv /var/lib/mysql/sitemanager /var/lib/mysql.old
# mv /root/backupdb/sitemanager/sitemanager /var/lib/mysql
# chown -R mysql. /var/lib/mysql
# systemctl start mysql

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

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

Готовим бэкап к восстановлению:

# xtrabackup – prepare – export – target-dir=/root/backupdb/full

Идем в консоль mysql и выбираем там таблицу для восстановления. В моем примере это будет таблица b_user_access из базы sitemanager. Смотрим, заполнена ли таблица данными.

mysql> SELECT COUNT(*) FROM sitemanager.b_user_access;
+----------+
| COUNT(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)

Делаем DISCARD этой таблицы.

mysql> ALTER TABLE sitemanager.b_user_access DISCARD TABLESPACE;
Query OK, 0 rows affected (0.00 sec)

Discard означает, что будет удален ibd файл таблицы. Теперь нам его нужно скопировать из бэкапа и назначить права для mysql.

# cp /root/backupdb/full/sitemanager/b_user_access.* /var/lib/mysql/sitemanager
# chown mysql. /var/lib/mysql/sitemanager/b_user_access.*

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

mysql> ALTER TABLE sitemanager.b_user_access IMPORT TABLESPACE;
Query OK, 0 rows affected (0.03 sec)

Смотрим, что получилось.

> SELECT COUNT(*) FROM sitemanager.b_user_access;
+----------+
| COUNT(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)

Данные восстановлены. Вернулись те же 6 строк, что и были до этого.

Бэкап и восстановление mysql с помощью mysqldump

Теперь просто для справки приведу примеры бэкапа и восстановления баз данных mysql с помощью mysqldump. Для небольших баз этого инструмента хватает за глаза и использовать что-то другое не имеет смысла. Преимущество xtrabackup в скорости работы и в возможности без проблем сделать инкрементный бэкап. Если он вам не нужен и база не большая, достаточно будет старого доброго mysqldump.

Бэкап всех баз mysql сервера с его помощью:

# /usr/bin/mysqldump -uroot -hlocalhost -p'password' – all-databases > /root/backupdb/all.sql

Можно сразу же сжимать его.

# /usr/bin/mysqldump -uroot -hlocalhost -p'password' – all-databases | /usr/bin/gzip -c > /root/backupdb/`date "+%Y-%m-%d"`sql.gz

Бэкап конкретной базы данных.

/usr/bin/mysqldump sitemanager -uroot -p'password' | /usr/bin/gzip -c > /root/backupdb/sitemanager_`date "+%Y-%m-%d"`sql.gz

Мне чаще всего мешают в дампе команды на создание базы данных — CREATE DATABASE, поэтому я их убираю ключом no-create-db.

/usr/bin/mysqldump – no-create-db sitemanager -uroot -p'password' | /usr/bin/gzip -c > /root/backupdb/sitemanager_`date "+%Y-%m-%d"`sql.gz

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

# mysql -uroot -p
mysql> use sitemanager;
mysql> source /root/backupdb/sitemanager.sql;

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

mysql> use sitemanager;
mysql> \. /root/backupdb/sitemanager.sql

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

#!/bin/bash

for i in `mysql -uroot -p'password' -e'show databases;' | grep -v information_schema | grep -v Database`; 
    do 
	/usr/bin/mysqldump -uroot -p'password' $i | /usr/bin/gzip -c > /root/backupdb/`date +%Y-%m-%d`-$i.sql.gz;
    done

Так же могу порекомендовать вот этот скрипт для бэкапа — https://github.com/adegtyarev/mysqlbackup. Описывать его не буду, по комментариям в скрипте понятен его функционал.

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

# cat sitemanager.sql | /usr/bin/awk '/CREATE TABLE `b_catalog_discount`/,/UNLOCK TABLES/' > /tmp/b_catalog_discount.sql

Дальше через source можно восстановить данные из этого дампа отдельной таблицы.

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

#!/bin/bash

USER='root'
PASS='R(zDXcVUmI[zwx%aNBTN'

MYSQL="mysql – user=$USER – password=$PASS – skip-column-names";
DIR="/root/backupdb"

for s in mysql `$MYSQL -e "SHOW DATABASES"`;
    do
    mkdir $DIR/$s;
    for t in `$MYSQL -e "SHOW TABLES FROM $s"`;
	do
	    /usr/bin/mysqldump – user="$USER" – password="$PASS" – opt $s $t | /usr/bin/gzip -c > $DIR/$s/$t.sql.gz;
	done
    done

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

for s in mysql sitemanager;

Восстановить потом всю базу из такого потабличного бэкапа можно таким образом.

#!/bin/bash
#

DB=sitemanager;
USER='root'
PASS='R(zDXcVUmI[zwx%aNBTN'
DIR="/root/backupdb/sitemanager"

for s in `ls -1 $DIR`;
    do
    echo "--> $s restoring... ";
    zcat $DIR/$s | /usr/bin/mysql – user=$USER – password=$PASS $DB;
    done

При использовании пароля в открытом виде в mysql или mysqldump, в консоль постоянно сыпятся предупреждения.

mysql: [Warning] Using a password on the command line interface can be insecure.

Чтобы их не было, перенесите, как я показывал выше, пароль в отдельный файл ~/.my.cnf, а из скрипта уберите авторизацию вообще.

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

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

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

К примеру, если работает интернет магазин или crm, делать бэкап раз в сутки по ночам не вариант. Надо намного чаще. Хотя бы каждые час-два. Полные дампы снимать не рационально в этом случае. Это и долго, и объем большой. Нужны инкрементные бэкапы.

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

Онлайн курс по Linux

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Администратор Linux» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров. Что даст вам этот курс:
  • Знание архитектуры Linux.
  • Освоение современных методов и инструментов анализа и обработки данных.
  • Умение подбирать конфигурацию под необходимые задачи, управлять процессами и обеспечивать безопасность системы.
  • Владение основными рабочими инструментами системного администратора.
  • Понимание особенностей развертывания, настройки и обслуживания сетей, построенных на базе Linux.
  • Способность быстро решать возникающие проблемы и обеспечивать стабильную и бесперебойную работу системы.
Проверьте себя на вступительном тесте и смотрите подробнее программу по .
Помогла статья? Подписывайся на telegram канал автора
Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.
Автоматизация настройки резервного копирования MS SQL с помощью .NET приложенияЯ долго созревал, чтобы написать данную статью и выложить свое приложение. Надеюсь вам будет интересно.
О чем данная статья

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

По максимум постараюсь описать те нюансы, с которыми мне пришлось столкнуться в ходе разработки приложения и настройки БД.
Для описанных ниже задач можно использовать мастер планов обслуживания, но мне больше понравился такой подход. Основное преимущество описанного мною метода, что данный способ можно применять ко всем версиям MS SQL (кроме Express, там немного другой подход). План обслуживания можно переносить, но у вас должна быть соответствующая в версия MS SQL и все равно будет создан Job для запуска плана обслуживания.

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

Кому подойдет данная статья:

  • Тем, у кого MS SQL Express и нет возможности запускать с помощью Job задачи
  • Тем, кто в ближайшем будущем планирует перейти с MS SQL 2008 на более новую версию и не хочет настраивать зеркалирование БД, а сразу на новой версии настроить AlwaysOn
  • Тем, у кого нет средств для поднятия еще резервных серверов и приходится обходиться тем, что есть.
  • У кого нет сжатых сроков на время восстановления БД. Главное – это результат
  • Кому лень что-то делать
  • Просто любопытным людям.

Оглавление:

Теория о резервном копирование

  1. Журнал транзакций
  2. Разностная копия БД
  3. Системные базы данных
  4. План бекапирования
  5. Общие рекомендации по резервному копированию

Используем приложение
  1. Настройка уведомления администратора
  2. Дополнительные уведомления для администратора
  3. Решение проблем при настройке DatabaseMail
  4. Настраиваем резервное копирование с помощью приложения для SQL Standart
  5. Настраиваем резервное копирование с помощью приложения для SQL Express
  6. Удаление задач из БД
  7. Удаление копий БД

Как восстанавливать резервные копии


Список статей хабра, которые я использовал

  1. Создание и хранение резервных копий баз данных в MS SQL. Практические советы
  2. Построение цепочки восстановлений баз данных MS SQL
  3. Настройка Database Mail в MS SQL Server 2005 и старше
  4. SQL Server 2008: бэкапим с умом. Часть 1: Теория
  5. Всё что вы стеснялись спросить о бэкапах Microsoft SQL Server

Исходники на github для MS SQL Standart и для MS SQL Express
Если появится желающие добавить свои мысли в код, принимаю pull request. Готов выслушать конструктивную критику и доработать приложение, если это действительно кому-то нужно будет.
Теория о резервном копирование

Все что описано в теории, вы можете найти самостоятельно. Конфигурации, которые описаны в данном разделе, автоматически будут выполнены моим приложением при настройке резервного копирования.
MS SQL Server поддерживает 3 модели резервного копирования.
  1. Простую
  2. Модель полного восстановление
  3. Модель полного восстановления с неполным протоколированием

Я выбрал для приложения модель полного восстановления, т.к. мне необходимо было иметь возможность всегда восстановить последнюю версию БД после любой операции и у меня не было одномоментных массовых операций по вставке данных. Если вы только начинаете и не знаете, как правильно выбрать, вам может помочь вот эта статья Microsoft.
Для включения данного режима, необходимо выполнить следующий скрипт
ALTER DATABASE [Имя базы данных] SET RECOVERY FULL;

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

  1. СУБД перестанет автоматически очищать журнал транзакций . Журнал будет расти до тех пор, пока не будет сделана его резервная копия. Это важный момент, администратору БД необходимо продумать вопрос о плане резервного копирования и очистки журнала. UPD: спасибо за помощь Yggaz
  2. Создание разностной резервной копии
  3. Создание полной резервной копии

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

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

Преимущества при восстановлении БД с помощью журнала транзакций:

  1. восстановление отдельных транзакций;
  2. восстановление всех незавершенных транзакций при запуске SQL Server;
  3. накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя и т.д

Рекомендации
  1. Вынести на быстрый жесткий диск, чтобы при большом потоке операций не было задержек при записи.
  2. Необходимо делать резервные копии журнала транзакций не реже чем каждый час.
  3. После создания полной (разностной) копии базы данных, все старые журналы можно удалять, т.к. они теряют свою актуальность.
  4. Внимательно следите за размером диска на котором хранятся журналы транзакций, если оно закончится, то записать новые данные в БД будет невозможно, пока не произойдет уменьшение размеров журнала транзакций или не добавиться новый дополнительный файл транзакций.
  5. Журнал транзакций необходимо регулярно усекать, чтобы избежать его переполнения. UPD: Как сказал kolu4iy данная операция по усечению слегка сомнительна в плане производительности, т.к. при бэкапирование журнал транзакции очищается внутри и СУБД начинает писать в нем по новой. Однако у вас может возникнуть ситуация, которую описал я в своем комментарии и тогда это вам может пригодиться.
  6. Возможна ситуация, когда невозможно сразу сделать усечение журнала. Они описаны в данной статье
  7. Для получения информации о состоянии базы данных можно с помощью следующего запроса:
    select name,log_reuse_wait, log_reuse_wait_desc  from sys.databases

  8. При необходимости можно получить информацию о последних открытых транзакциях
    DBCC OPENTRAN (Имя базы данных) WITH TABLERESULTS
    

Пример SQL скрипта для выполнения резервного копирования журнала транзакции с последующим усечением файла.
BACKUP LOG [Имя базы данных] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL\MSSQL\Backup\[Имя файла].bak' WITH NOFORMAT, NOINIT, 
NAME = N'Журнал транзакций  Резервное копирование', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO
USE [Имя базы данных]
GO
DBCC SHRINKFILE (N'Имя файла лога БД' , 25)
GO

Эти же операции можно проделать с помощью SSMS
2.Разностная копия БД

Разностное резервное копирование основано на самой последней предыдущей полной резервной копии данных. В разностной резервной копии сохраняются только те изменения, которые были произведены с момента создания последней полной резервной копии.
Рекомендации:
  1. Используйте разностные копии БД, если создание полной копии БД занимает большой промежуток времени
  2. Периодически делайте полную копию БД, чтобы уменьшить объемы создаваемых разностных копий.
  3. После создания полной копии БД, все предыдущие разностные копии теряют свою актуальность.

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

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

Пример SQL для создания резервной разностной копии БД с проверкой копии по завершению (отличается от полного копирования флагом DIFFERENTIAL вместо него нужно использовать NOFORMAT).

declare @pathBackup as varchar(55)
set @pathBackup =  N'C:\Backup\[Имя файла БД]_' + REPLACE(convert(varchar,GETDATE(), 104),'.','_') + '.bak'
BACKUP DATABASE [Имя базы данных] TO  DISK = @pathBackup
WITH DIFFERENTIAL, NOFORMAT, INIT, NAME = N'Полная База данных Резервное копирование', SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM
GO
declare @backupSetId as int
declare @pathBackup as varchar(55)
set @pathBackup =  N'C:\Backup\[Имя файла БД]_' + REPLACE(convert(varchar,GETDATE(), 104),'.','_') + '.bak'
select @backupSetId = position from msdb..backupset where database_name=N'[Имя базы данных]' 
and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'[Имя базы данных]')
if @backupSetId is null 
begin 
	raiserror(N'Ошибка верификации. Сведения о резервном копировании для базы данных "[Имя базы данных]" не найдены.', 16, 1) 
end
RESTORE VERIFYONLY FROM  DISK = @pathBackup
WITH FILE = @backupSetId,  NOUNLOAD,  NOREWIND
GO
3.Системные базы данных

Помимо основной базы и связанных с ней файлов, я настоятельно рекомендую делать копии и системных баз данных. Начнем с того, что рассмотрим какие базы существуют в MS SQL. Их всего 5:
Название
Описание
База данных master
В этой базе данных хранятся все данные системного уровня для экземпляра SQL Server.
База данных msdb
Используется агентом SQL Server для планирования предупреждений и задач.
База данных model
Используется в качестве шаблона для всех баз данных, создаваемых в экземпляре SQL Server. Изменение размера, параметров сортировки, модели восстановления и других параметров базы данных model приводит к изменению соответствующих параметров всех баз данных, создаваемых после изменения.
База данных resource
База данных только для чтения. Содержит системные объекты, которые входят в состав SQL Server. Системные объекты физически хранятся в базе данных Resource, но логически отображаются в схеме sys любой базы данных.
База данных tempdb
Рабочее пространство для временных объектов или взаимодействия результирующих наборов.

Более подробно можете прочитать о них тут и еще вот тут.

Я выбрал резервировать только 2 системные БД:

  1. msdb – потому что, там хранятся настроенные задачи и другие
  2. master – хранятся все произведенные настройки SQL Server.

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

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

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

  • Полная копия основной БД, чаще чем раз в неделю нет необходимости
  • Разностная копия основной БД, каждый день
  • Копии журнала транзакций основной БД, каждый час
  • Копия системной БД master, раз в неделю
  • Копия системной БД msdb, раз в неделю

В итоге у нас получился следующий план резервного копирования данных:
День недели
Время
Действия
Частота
Описание
Понедельник — Пятница
С 8-00 до 21-00
Резервные копии

Журнала транзакций

Каждый час
После выполнения резервной копии БД идет сжатие и усечение журнала транзакций
Суббота — Воскресенье
С 8-00 до 18-00
Понедельник – Воскресенье
22-00
Разностная копия основной БД
1 раз в день
После успешного выполнения разностной копии удаляются все старые копии журнала транзакций
Суббота
12-00
Проверка БД
1 раз в день
Проверка БД Дело на целостность.
Суббота
18-00
Создание полной копии БД
1 раз в день
По завершению данной операции идет уведомление на почту.

 

Если создание резервной копии прошло удачно, удаляется

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

Понедельник – Воскресенье
23-30
Создание копии системной базы master
1 раз в день
Хранится всегда только последний экземпляр БД
Воскресенье
12-30
Создание копии системной базы msdb
1 раз в месяц
Хранится всегда только последний экземпляр БД
5. Общие рекомендации по резервному копированию

  1. Используйте опцию
    BACKUP WITH CHECKSUM

    чтобы убедиться, что все прошло хорошо. Недостатком такого решения является то, что для больших баз данных проверка контрольной суммы может серьезно загрузить систему.
  2. Не выполняйте резервное копирование файлов на тот же физический диск, на котором хранится база данных или протокол транзакций.
  3. Если вы используете MS SQL 2008 или выше, рекомендую вам использовать сжатие резервных копий средствами SQL. Следующий код включит сжатие по умолчанию:
    USE master; GO EXEC sp_configure ‘backup compression default’, '1'; RECONFIGURE WITH OVERRIDE;
  4. держите резервные копии по нескольку дней на случай, если одна из них будет повреждена – старая резервная копия лучше, чем никакой.
  5. Используйте DBCC CHECKDB для проверки каждой базы данных перед копированием, это своевременно предупредит вас о надвигающихся проблемах.
    DBCC CHECKDB ('Имя базы данных') WITH NO_INFOMSGS,   ALL_ERRORMSGS;
    Примечание: на практики мы использовали данную проверку, только перед выполнением полной резервной копии.
  6. Выполняйте периодически обновление статистики и реорганизации индексов БД
Используем приложение

Несколько нюансов по приложению:
  • Все тексты и запросы в коде вынесены в ресурсы, мне так было проще
  • При вводе параметров соединения и других настроек, они сохраняются в файл. Для Express и Standart используются разные файлы (dbStandart, udExpress) в них хранится класс UserData
  • Для выполнения некоторых операций могут потребоваться права администратора
  • На данный момент не работает соединение с БД под доменной учетной записью
  • Программа не обладает суперкрасивым интерфейсом
1. Настройка уведомления администратора

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

Для данной цели используется DatabaseMail MS SQL (для версии Standart и выше)
В своем приложение я сделал специальный раздел для автоматизации данной задачи

При нажатии появится форма для заполнения информации необходимой для создания профиля рассылки писем:

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

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

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

  1. Меняются системные параметры MS SQL.
  2. Создается DatabaseMail Profile
  3. Активируется в SQL Agente профиль
  4. Создается DatabaseMail Account
  5. Добавляется DatabaseMail Account к Database Mail Profile
  6. Создается DatabaseMail Operator

Более подробно описано в следующей статье и, частично, я брал отсюда. Естественно, данные действия можно выполнить с помощью SSMS.
2.Дополнительные уведомления для администратора

В программе предусмотрены 2 задачи, применяемые к БД:
  1. проверка целостности БД. Для проверки базы данных использовалась стандартная процедура DBCC CHECKDB.
  2. информирование о свободном месте в файловых группах.
  3. Вторая задача была реализована с помощью запроса к системной таблице dbo.sysfiles
  4. Вот пример данного запроса, который выполнялся к базе:
Select 
 NAME = left(a.NAME,15),
 a.FILEID,
 [FILE_SIZE_MB] = convert(decimal(12,2),round(a.size/128.000,2)),
 [SPACE_USED_MB] = convert(decimal(12,2),round(fileproperty(a.name,'SpaceUsed')/128.000,2)),
 [FREE_SPACE_MB] = convert(decimal(12,2),round((a.size-fileproperty(a.name,'SpaceUsed'))/128.000,2)) ,
 FILENAME = a.FILENAME
From dbo.sysfiles a

Ответ с сервера приходит на почту администратора в виде html разметки. Данный синтаксис возможен благодаря следующей стандартной функции MS SQL FOR XML.

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

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

3.Решение проблем при настройке DatabaseMail

В MS SQL 2008 я столкнулся с проблемой при настройке SQL Server Agent. Симптомы следующие, после настройки невозможно запустить SQL Agent. В основном это решается с помощью установки update на SQL сервер.

Убедитесь, что установлен sp1, а потом можно уже ставить обновление.

Если данные обновления не помогают, необходимо скачать fix. Его можно найти на данном сайте конечную ссылку не могу указать сейчас, для того что бы дойти до пакета фикса, нужно будет ответить на ряд вопросов.
Если есть проблемы с модулем DatabaseMail. После настройки данного модуля с помощью приложения, необходимо зайти в SQL Agent и просмотреть журнал событий. Если там будут ошибки «невозможно подключиться к почтовому ящику». Значит есть проблема, даже если через проверку отправляется письмо.

Исправляется это следующими манипуляциями:

  1. Management Studio — SQL Server Agent — Properties.
  2. Alert System
  3. Уберите галочку с Enable mail profile
  4. Нажмите OК
  5. Зайдите снова и поставьте галочку
  6. Перезагрузите SQL Server Agent.

Проверьте учетную запись для SQL Agent service. Если это доменная учетная запись измените ее на системную или наоборот. Все должно заработать.
4.Настраиваем резервное копирование с помощью приложения для SQL Standart:

Выбираем версию Standart. Настраиваем уведомления. (см. раздел, настройки уведомления):

Соединяемся с БД, заполняя данные для соединения и указываем БД, для которой будет применяться Job:

Выбираем настройку резервного копирования:

Указываем пути для сохранения копий БД. Если указанные папки не существует, то программа попытается их создать (нужны соответствующие права).

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

5.Настраиваем резервное копирование с помощью приложения для SQL Express:

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

Для этого запускаем приложение. Выбираем пункт MS SQL Express:

Появляется форма для заполнения параметров:

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

Единственный минус данного подхода в том, что приходится храниться в открытом виде пароль для соединения с БД.

6.Удаление задач из БД.

Если необходимо удалить все задачи из БД (например, захотели изменить пути сохранения БД). Для этого используем соответствующий пункт в меню программы. Из SQL Agent будут удалены все задачи с определенным начальным префиксом (в моем случае King):

7.Удаление копий БД

В некоторых задачах, настроено удаление старых копий БД. Для этого я использую процедуру master.dbo.xp_delete_file. Пример использования: Удалит все файлы с расширением bak из указанной папки, дата создания которых превышает 14 дней.

EXECUTE master.dbo.xp_delete_file 0,"E:\backups",N'bak',dateadd(d,-14,getdate()),0;

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

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

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

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


RESTORE DATABASE [Имя базы данных] FROM DISK = 'Z:\SQLServerBackups\back.bak' WITH REPLACE

В случае, если необходимо восстановить последовательно сначала полную копию, разностные копии и журналы транзакций, тогда необходимо написать следующий SQL скрипт.
RESTORE DATABASE TEST_DB –восстанавливаем полную копию
   FROM test_db_full
   WITH NORECOVERY;
GO
RESTORE DATABASE TEST_DB –восстанавливаем разностную копию
   FROM test_db_diff
   WITH FILE = 1,
   NORECOVERY;
GO
RESTORE LOG TEST_DB –восстанавливаем журнал транзакций №1
   FROM test_db_tran_1
   WITH FILE = 1,
   WITH NORECOVERY;
GO
RESTORE LOG TEST_DB –восстанавливаем журнал транзакций №2
   FROM test_db_tran_2
   WITH FILE = 1,
   WITH NORECOVERY;
GO
RESTORE DATABASE TEST_DB
   WITH RECOVERY;
GO

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

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

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

Пример из жизни. Недолгое время у одного из наших заказчиков работал некий товарищ, который, хоть был еще не стар, вел себя как Леонид Ильич в рассвете паралитических недугов. Он ходил вразвалку, неторопливо и с наслаждением разговаривал, то и дело причмокивая. Любая деталь подолгу занимала его внимание. Однажды он набирал в юниксовой консоли команду rm -rf, и перед тем, как его отвлекли разговором, он успел еще добавить слэш, после чего переключился на собеседника. Когда разговор закончился, товарищ обернулся к монитору, нахмурился, силясь вспомнить, чем до этого занимался, и решительно прогнал проклятый скринсейвер, нажав на Enter. Надо ли говорить, что в этот момент информация, весело шурша винчестерами, удалялась со всех копий RAID и даже с удаленных реплик массива. Кстати, после этого случая я всегда возвращаю компьютер из режима сна клавишей Alt — так безопаснее.

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

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

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

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

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

Еще более предпочтительными являются дисковые хранилища, по мере удешевления производства это перестало быть роскошью. СХД отличаются скоростью работы и надежностью, конечно, при условии, что используется RAID. Есть так называемые виртуальные библиотеки – VTL – которые умеют прикидываться ленточной библиотекой, но данные записывают на диски.

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

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

Как это можно организовать? В простом случае кассеты извлекаются из библиотеки, и их отвозит куда-нибудь в Химки водитель дядя Вася. Понятно, что при восстановлении также участвует дядя Вася, поэтому он во всей цепочке является самой медленной стадией. Ну а для тех, кто сумел построить или использует на аутсорсинге полноценный резервный ЦОД с хорошим каналом, резервные копии можно автоматически дублировать при помощи современных средств резервного копирования. Например, имея на каждой площадке по АПК Symantec NetBackup Appliance, можно получить полноценный DR-сайт, куда резервные копии с основной площадки попадают при помощи технологии Automatic Image Replication (AIR).

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

В давние времена ночью все пользователи спали, и окно резервного копирования могло длиться, например, с 11 вечера до 7 утра. За это время все данные успевали скопироваться. Когда стало расти число систем, которые обслуживают запросы клиентов и ночью, скорость создания резервных копий стала иметь большее значение. Теперь нужно уложиться в пару-тройку часов, а для систем, работающих 24х7, в минуты. Именно поэтому рынок систем резервного копирования продолжает активно развиваться, изобретая все новые подходы.

8. Данные можно копировать по SAN, а не по LAN.
Большой поток копируемых данных нагружает сеть. Существует техника, которая называется LAN-free backup. Если СХД с данными и библиотеки подключены в SAN (сеть хранения данных), то вполне разумно передавать данные между СХД и библиотекой напрямую по SAN, при этом исключив загрузку локальной сети. Это часто бывает и быстрее, потому что далеко не везде локальная сеть построена на 10G, а обычный 1GB ethernet сильно уступает по пропускной способности даже не самой современной SAN.

9. Приложения можно бэкапить на ходу…
Создать консистентную копию данных, например, СУБД Oracle или MS Exchange без остановки работы невозможно: информация непрерывно меняется, часть ее находится в буферах, в оперативной памяти. У серьезных продуктов промышленного класса, таких как Symantec NetBackup, EMC Networker, CommVault Simpana и др., есть широкий спектр агентов для работы с различными бизнес-приложениями. Эти агенты умеет перевести приложение в режим, когда буфер сбрасывается на диск, а файлы с данными на время перестают меняться.

10. …и минимизировать нагрузку на основную систему.
Чтобы не держать приложение долго в таком режиме работы, эту технику можно скомбинировать с созданием снапшотов — мгновенных снимков данных. Снапшот создается быстро, после чего приложение можно «отпустить», а копировать консистентные данные уже со снапшота. Для создания снапшотов применяются в свою очередь свои агенты, которые также могут входить в состав программного обеспечения для резервного копирования.

Если создать не просто снапшот данных, а клон, то его можно отсоединить от исходного диска с данными и передать через SAN на другой хост. И уже на другом хосте программа резервного копирования увидит эти данные и будет передавать их на резервное хранилище. Это техника называется Offhost backup.

11. Виртуальные машины нужно стараться бэкапить средствами гипервизора.
Современные гипервизоры, такие как VMware ESXi, предоставляют инструменты по созданию образов виртуальных машин на лету, без остановки их работы. По сути — те же снапшоты. Такой образ виртуалки бэкапится как файл, а вот топовым функционалом средств резервного копирования является возможность восстанавливать из этого образа гранулярно любой объект, например, единичное письмо электронной почты, если внутри виртуалки работал почтовый сервер. Самыми продвинутыми возможностями тут, по моему мнению, обладают продукты от Symantec.

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

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

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

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

Резервное копирование и восстановление — база данных Azure для MySQL
  • 5 минут, чтобы прочитать

В этой статье

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

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

База данных Azure для MySQL создает резервные копии файлов данных и журнала транзакций. В зависимости от поддерживаемого максимального размера хранилища мы принимаем либо полное и разностное резервное копирование (серверы хранения максимум 4 ТБ), либо резервное копирование моментальных снимков (до 16 серверов хранилища максимум).Эти резервные копии позволяют восстановить сервер в любой момент времени в течение настроенного вами периода хранения резервных копий. Срок хранения резервной копии по умолчанию составляет семь дней. При желании вы можете настроить его до 35 дней. Все резервные копии зашифрованы с использованием 256-разрядного шифрования AES.

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

Резервная частота

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

Варианты резервного резервирования

База данных

Azure для MySQL обеспечивает гибкость выбора между локально избыточным или гео-избыточным хранилищем резервных копий на уровнях общего назначения и оптимизации памяти. Когда резервные копии хранятся в гео-избыточном хранилище резервных копий, они не только хранятся в пределах региона, в котором размещен ваш сервер, но также реплицируются в парный центр обработки данных. Это обеспечивает лучшую защиту и возможность восстановления вашего сервера в другом регионе в случае аварии.Базовый уровень предлагает только локально избыточное хранилище резервных копий.

Важно

Настройка локально избыточного или гео-избыточного хранилища для резервного копирования разрешена только при создании сервера. После подготовки сервера вы не можете изменить параметр резервирования хранилища резервных копий.

Стоимость резервного хранилища

База данных

Azure для MySQL обеспечивает до 100% выделенного хранилища сервера в качестве хранилища резервных копий без дополнительных затрат. Как правило, это подходит для резервного копирования в течение семи дней.Любое дополнительное хранилище резервируется в ГБ-месяце.

Например, если вы предоставили серверу 250 ГБ, у вас есть 250 ГБ хранилища резервных копий без дополнительной оплаты. Хранение свыше 250 ГБ взимается.

Восстановить

В базе данных Azure для MySQL при выполнении восстановления создается новый сервер из резервных копий исходного сервера и восстанавливаются все базы данных, содержащиеся на сервере.

Существует два типа восстановления:

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

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

Важно

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

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

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

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

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

Гео-восстановление

Вы можете восстановить сервер в другом регионе Azure, где эта служба доступна, если вы настроили свой сервер для резервирования с географическим резервированием. Серверы, поддерживающие до 4 ТБ хранилища, могут быть восстановлены в геопарном регионе или в любом регионе, поддерживающем до 16 ТБ хранилища. На серверах, которые поддерживают до 16 ТБ хранилища, гео-резервные копии могут быть восстановлены в любом регионе, который также поддерживает 16 ТБ серверов.Просмотрите список поддерживаемых регионов в базе данных Azure для баз данных MySQL.

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

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

Выполнить задачи после восстановления

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

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

Следующие шаги

,
Резервное копирование и восстановление базы данных

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

    Резервное копирование базы данных
  • — это хранилище данных, которое означает копию данных.
  • Это защита от неожиданной потери данных и ошибок приложения.
  • Защищает базу данных от потери данных.
  • Если исходные данные потеряны, то с помощью резервной копии их можно восстановить.
Резервные копии делятся на два типа,
1. Физическая резервная копия
2. Логическое резервное копирование

1. Физические резервные копии

  • Физические резервные копии — это резервные копии физических файлов, используемых при хранении и восстановлении вашей базы данных, таких как файлы данных, контрольные файлы и архивированные журналы повторов, файлы журналов.
  • Это копия файлов, хранящих информацию базы данных в другом месте, например на диске, в каком-либо автономном хранилище, например на магнитной ленте.
  • Физические резервные копии являются основой механизма восстановления в базе данных.
  • Физическое резервное копирование предоставляет подробные сведения о транзакции и модификации базы данных.
2. Логическая резервная копия
  • Логическая резервная копия содержит логические данные, которые извлекаются из базы данных.
  • Включает в себя резервное копирование логических данных, таких как представления, процедуры, функции, таблицы и т. Д.
  • Это полезное дополнение к физическим резервным копиям при многих обстоятельствах, но не достаточная защита от потери данных без физических резервных копий, поскольку логическое резервное копирование обеспечивает только структурное резервное копирование. Информация.

Важность резервных копий

  • Планирование и тестирование резервного копирования помогает против сбоев носителя, операционной системы, программного обеспечения и любых других сбоев, которые вызывают серьезный сбой данных.
  • Определяет скорость и успешность восстановления.
  • Физическое резервное копирование извлекает данные из физического хранилища (обычно с диска на ленту). Операционная система является примером физического резервного копирования.
  • Логическая резервная копия извлекает данные с использованием SQL из базы данных и сохраняет их в двоичном файле.
  • Логическое резервное копирование используется для восстановления объектов базы данных в базу данных. Таким образом, утилиты логического резервного копирования позволяют DBA (администратору базы данных) выполнять резервное копирование и восстановление выбранных объектов в базе данных.

Хранение данных

Хранение данных — это структура памяти в системе.

Хранение данных делится на три категории:
1. Энергозависимая память
2. Энергонезависимая память
3. Стабильная память

1. Энергозависимая память

  • Энергозависимая память может хранить только небольшой объем памяти. данные.Например, Основная память, кэш-память и т. Д.
  • Энергозависимая память является основным запоминающим устройством в системе и размещается вместе с процессором.
  • В энергозависимой памяти при сбое системы данные будут потеряны.
  • RAM — это основное устройство хранения, которое хранит дисковый буфер, активные журналы и другие связанные данные базы данных.
  • Первичная память всегда быстрее вторичной памяти.
  • Когда мы запускаем запрос, база данных извлекает данные из первичной памяти, а затем перемещается во вторичную память для извлечения записи.
  • Если происходит сбой первичной памяти, то все данные в первичной памяти теряются и не могут быть восстановлены.
  • Чтобы избежать потери данных, создайте копию первичной памяти в базе данных со всеми журналами и буферами, создайте контрольные точки в нескольких местах, чтобы данные копировались в базу данных.
2. Энергонезависимая память
  • Энергонезависимая память является вторичной памятью.
  • Эти воспоминания огромны по размеру, но медленны в обработке. Например, Флэш-память, жесткий диск, магнитные ленты и т. Д.
  • В случае сбоя вторичной памяти все данные в первичной памяти теряются и не могут быть восстановлены.
Чтобы избежать потери данных во вторичной памяти, для ее резервного копирования используются три метода:

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

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

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

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

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

3. Стабильная память

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

Причины сбоев базы данных

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

  • Существует несколько распространенных причин сбоев, например,
    1. Сбой системы
    2. Сбой транзакции
    3. Сбой сети
    4. Сбой диска
    5. Сбой носителя
  • Каждая транзакция имеет свойство ACID. Если мы не можем поддерживать свойства ACID, это сбой системы базы данных.
1. Сбой системы
  • Сбой системы происходит в случае сбоя оборудования или программного обеспечения или внешних факторов, таких как сбой питания.
  • На данные во вторичной памяти не влияют сбой системы, поскольку база данных обладает достаточной целостностью. Контрольная точка предотвращает потерю данных из вторичной памяти.
2. Сбой транзакции
  • На сбой транзакции влияют только несколько таблиц или процессов из-за логических ошибок в коде.
  • Этот сбой происходит, когда существуют системные ошибки, такие как тупик или недоступность системных ресурсов для выполнения транзакции.
3. Отказ сети
  • Отказ сети происходит, когда клиент-серверная конфигурация или система распределенной базы данных соединены сетями связи.
4. Отказ диска
    Отказ диска
  • возникает, когда возникают проблемы с жесткими дисками, такие как образование поврежденных секторов, сбой головки диска, недоступность диска и т. Д.
5. Сбой носителя
  • Сбой носителя — это наиболее опасный сбой, потому что восстановление занимает больше времени, чем любой другой вид сбоев.
  • Сбой контроллера диска или головки диска — типичный пример сбоя носителя.
  • Стихийные бедствия, такие как наводнения, землетрясения, перебои в подаче электроэнергии и т. Д., Повреждают данные.
,

Минутку …

Пожалуйста, включите Cookies и перезагрузите страницу.

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

Пожалуйста, подождите до 5 секунд …

+ ((! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + []) + (! + [] + (!! []) + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [ ] + !! [] + !! []) + (+ [] — (!! [])) + (! + [] + (!! []) + !! [] + !! []) + (+ !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! []) + (! + [] + ( !! []) + !! [] + !! []) + (+ !! [])) / + ((+ !! [] + []) + (! + [] + (!! [] ) + !! []) + (+ !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] +! ! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! [] ) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! []))

+ ((! + [] + (!! []) + !! [ ] + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + []) + (! + [] + (!! []) +! ! [] + !! []) + (+ !! []) + (+ [] — (!! []) (! + [] + (!! [])) + + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (+ !! [])) / + (( ! + [] + (!! []) — [] + []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [ ] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! []) + (! + [] + (! ! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] +! ! [] + !! []) + (+ [] — (!! [])) + (! + [] + (!! []) + !! [] + !! [] + !! [ ] + !! [] + !! [] + !! [] + !! []))

+ ((! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + []) + (! + [] + (!! []) + !! [] + !! [ ]) + (+ !! []) + (+ [] — (!! []) (! + [] + (!! [])) + + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (+ !! [])) / + ((! + [] + (! ! []) + !! [] + !! [] + !! [] + !! [] + !! [] + []) + (+ !! []) + (! + [] + (! ! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! []) + (+ [] + (!! []) — []) + (+! ! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! []) + (! + [] + (!! []) — []))

+ ((! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + []) + (! + [] + (!! []) + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (+ [] — (!! [])) + (! + [] + (!! []) + !! [] + !! []) + (+ !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [ ] + !! []) + (+ !! [])) / + ((! + [] + (!! []) + !! [] + !! [] + []) + (! + [ ] + (!! []) + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! []) + (! + [] + (!! []) +! ! [] + !! []) + (+ [] + (!! [!]) — []) + (+ [] + (!! [!]) — []) + (+ [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! []))

+ ((! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + []) + (! + [] + (!! [] ) + !! [] + !! []) + (+ !! []) + (+ [] -! (!! [])) + (+ [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (+ !! [])) / + ((! + [] + (!! []) + !! [] + !! [] + []) + (! + [] + (!! []) + !! [] + !! [ ] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] ) + (+ !! []) + (! + [] + (!! []) + !! [] + !! []) + (! + [] + (!! []) + !! [ ] + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! []) + (! + [] + (!! []) + !! [] + !! []))

+ ((! + [] + (!! []) + !! [] + !! [] + !! [] + !! [ ] + !! [] + !! [] + []) + (! + [] + (!! []) + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! [] ) + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! []) + (! + [] — (!! [])) + (! + [] + (!! []) + !! [])) / + ((+ !! [] + []) + (+ [] + (! ! []) + !! [] + !! [] + !! [] + !! [] +! ! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! []) + ( ! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! []) + (! + [] + (!! []) — []) + (+ [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (+ !! []))

+ ((! + [] + (!! []) + !! [] + !! [] + !! [] + !! [ ] + !! [] + !! [] + []) + (! + [] + (!! []) + !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! [] + !! [] + !! []) + (+ [] — (!! []!)) + (+ [] + ( !! []) + !! [] + !! []) + (+ !! []) + (! + [] + (!! []) + !! [] + !! [] + !! [] + !! []) + (! + [] + (!! []) + !! [] + !! []) + (+ !! [])) / + ((! + [] + (!! []) + !! [] + !! [] + !! [] + []) + (+ !! []) + (+ !! []) + (! + [] + (! ! []) — []) + (+ [] -! (!! [])) + (+ [] + (!! []) + !! [] + !! []) + (+ [] + (!! []) + !! [] + !! [] + !! [] + !! []) + (+ !! []) + (! + [] + (!! [] ) + !! [] + !! [] + !! [] + !! [] + !! [] + !! [] + !! []))

,
Как восстановить базу данных SQL Server из резервной копии

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

  1. с использованием команд T-SQL
  2. с использованием SQL Server Management Studio
  3. с использованием приложения SqlBackupAndFtp

Как восстановить базу данных SQL Server из резервной копии с помощью команд T-SQL

Команда

RESTORE DATABASE — это самый простой и универсальный способ восстановления резервных копий SQL Server, поскольку команды T-SQL работают везде, независимо от того, вводите ли вы их в SQL Server Management Studio, выполняете с помощью утилиты sqlcmd или запускаете из своей программы.Давайте рассмотрим, какие команды используются для восстановления трех типов резервного копирования: полное, разностное и резервное копирование журнала транзакций.

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

содержат всю информацию, необходимую для восстановления базы данных до того момента, когда процесс резервного копирования завершится. Резервная копия перезапишет вашу базу данных, если таковая существует, или создаст новую базу данных SQL Server. Пусть ваша полная резервная копия хранится в D: \ Adventureworks_full.bak, и вы хотите восстановить ее в базе данных Adventureworks.Вам необходимо выполнить следующие команды:

 ВОССТАНОВИТЬ БАЗУ ДАННЫХ Adventureworks FROM DISK = 'D: \ Adventureworks_full.bak' 

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

 ВОССТАНОВИТЬ БАЗУ ДАННЫХ Adventureworks FROM DISK = 'D: \ Adventureworks_full.bak' С NORECOVERY 
Восстановление разностной резервной копии базы данных SQL Server

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

 ВОССТАНОВИТЬ БАЗУ ДАННЫХ Adventureworks FROM DISK = 'D: \ Adventureworks_full.bak' С NORECOVERY
ИДТИ
ВОССТАНОВИТЬ БАЗУ ДАННЫХ Adventureworks FROM DISK = 'D: \ AdventureWorks_diff.диф с восстановлением
GO 
Восстановление журнала транзакций Резервное копирование базы данных SQL Server

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

 ВОССТАНОВИТЬ БАЗУ ДАННЫХ Adventureworks FROM DISK = 'D: \ Adventureworks_full.бак с NORECOVERY
ИДТИ
ВОССТАНОВИТЬ БАЗУ ДАННЫХ Adventureworks FROM DISK = 'D: \ AdventureWorks_diff.dif' С NORECOVERY
ИДТИ
ВОССТАНОВИТЬ ЛОГК Adventureworks FROM DISK = 'D: \ Adventureworks_log1.trn' С NORECOVERY
ИДТИ
ВОССТАНОВИТЬ ЖУРНАЛ Adventureworks FROM DISK = 'D: \ Adventureworks_log2.trn' С ВОССТАНОВЛЕНИЕМ
GO 

Как восстановить базу данных из резервной копии с помощью SQL Server Managment Studio

Если у вас установлена ​​SQL Server Management Studio, вы можете восстановить резервную копию базы данных, используя только ее интерфейс.Просто следуйте инструкциям:

1. Подключитесь к вашему SQL Server, щелкните правой кнопкой мыши по каталогу «Базы данных» и выберите «Восстановить базу данных».

ssms restore database
2. Нажмите кнопку под разделом «Источник» рядом с «Устройством»
3. В «Выбор устройства резервного копирования» нажмите «Добавить»
4. Выберите файл или файлы резервной копии (.bak), к которым вы собираетесь подключиться. восстановить, затем нажать «ОК»
5. В окне «Восстановить базу данных» указать имя базы данных, которую вы будете восстанавливать, и нажать «ОК» для запуска ssms restore options

База данных SQL Server восстановлена.

Как восстановить базу данных SQL Server с помощью SqlBackupAndFtp

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

ssms restore options

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

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

Если вам необходимо восстановить другие резервные копии, которые были созданы с помощью SqlBackupAndFtp, или стандартной команды T-SQL «CREATE BACKUP», или сценария SQL или файла .bacpac, то, выполнив следующие шаги, вы можете создать «задание восстановления», чтобы сделай это:

  1. Выберите место, где хранятся ваши резервные копии
  2. Подключитесь к серверу, на который нужно восстановить резервные копии
  3. Выберите базу данных для восстановления
  4. Нажмите «Запустить сейчас»

ssms restore options

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

 {DatabaseName} {ГГГГ} {ММ} {ДД} {чч} {мм} [log | diff].[sql | bacpac | 7z | zip | bak] 

,

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

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