Бэкап базы что это
Резервное копирование данных в MySQL
1. Копирование файлов базы
Базу данных MySQL можно скопировать, если временно выключить MySQL-сервер и просто скопировать файлы из папки /var/lib/mysql/db/. Если сервер не выключить, по очевидным причинам вероятна потеря и порча данных. Для больших нагруженных баз эта вероятность близка к 100%. Кроме того, при первом запуске с «грязной» копией базы данных MySQL-сервер начнет процесс проверки всей базы, который может затянуться на часы.
В большинстве «живых» проектов регулярное выключение сервера БД на длительное время неприемлемо. Для решения этой проблемы применяется трюк, основанный на снэпшотах файловой системы. Снэпшот — это что-то вроде «фотографии» файловой системы на определенный момент времени, сделанный без реального копирования данных (и потому быстро). Аналогичным образом работает «ленивое копирование» объектов во многих современных языках программирования.
Общая схема действий такова: блокируются все таблицы, сбрасывается файловый кэш БД, делается снэпшот файловой системы, разблокируются таблицы. После этого файлы спокойно копируются из снэпшота, после чего он уничтожается. «Блокирующая» часть такого процесса занимает время порядка секунд, что уже терпимо. В качестве расплаты на какое-то время, пока «жив» снэпшот, снижается производительность файловых операций, что в первую очередь бьет по скорости операций записи в базу.
Некоторые файловые системы, например, ZFS, поддерживают снятие снэпшотов нативно. Если вы не пользуетесь ZFS, но на вашем сервере стоит менеджер томов LVM, вы также сможете скопировать базу MySQL через снэпшот. Наконец, под *nix можно воспользоваться драйвером снэпшотов R1Soft Hot Copy, но этот способ не заработает в контейнере openvz (процесс бэкапа MySQL описан здесь).
Для баз MyISAM существует официальная бесплатная утилита mysqlhotcopy, которая «правильно» копирует файлы баз MyISAM без остановки сервера. Существует аналогичная утилита для InnoDB, но она платная, хотя и возможностей в ней больше.
Копирование файлов — самый быстрый способ перебросить базу данных целиком с одного сервера на другой.
2. Копирование через текстовые файлы
Для того, чтобы считать в бэкап данные из production-базы, необязательно дергать файлы. Можно выбрать данные запросом и сохранить их в текстовый файл. Для этого используется SQL-команда SELECT INTO OUTFILE и парная ей LOAD DATA INFILE. Выгрузка производится построчно (можно отобрать для сохранения только нужные строки, как в обычном SELECT). Структура таблиц нигде не указывается — об этом должен заботиться программист. Он также должен позаботиться о включении команд SELECT INTO OUTFILE в транзакцию, если это необходимо для обеспечения целостности данных. На практике SELECT INTO OUTFILE используется для частичного бэкапа очень больших таблиц, которые нельзя скопировать никаким другим образом.
В большинстве случаев намного более удобна созданная Игорем Романенко утилита mysqldump. Утилита mysqldump формирует файл, содержащий все SQL-команды, необходимые для полного восстановления БД на другом сервере. Отдельными опциями можно добиться совместимости этого файла с практически любой СУБД (не только MySQL), кроме того, существует возможность выгрузки данных в форматах CSV и XML. Для восстановления данных из таких форматов существует утилита mysqlimport.
Утилита mysqldump консольная. Существуют её надстройки и аналоги, позволяющие управлять бэкапом через веб-интерфейс, например, украинская тулза Sypex Dumper (их представитель zapimir есть на хабре).
Недостатки универсальных утилит бэкапа в текстовые файлы — это относительно невысокая скорость работы и отсутствие возможности делать инкрементные бэкапы.
3. Инкрементные бэкапы
Традиционно рекомендуют держать 10 бэкапов: по одному на каждый день недели, а также бэкапы двухнедельной, месячной и квартальной давности — это позволит достаточно глубоко откатиться в случае порчи каких-либо данных.
Храниться бэкапы должны точно не на том же диске, что и живая база, и не на том же сервере. На случай пожаров и прочих катаклизмов лучше всего арендовать пару юнитов в соседнем дата-центре.
Эти требования могут стать проблемой для больших баз. Прокачка бэкапа 100-гигабайтной базы по 100-мбитной сети займет часа три, на которые полностью забьет канал.
Частично решить эту проблему позволяют инкрементные бэкапы, когда полный бэкап делается, скажем, только по воскресеньям, а в остальные дни пишутся только данные, добавленные или измененные за прошедшие сутки. Сложность в том, как выявить эти самые «данные, изменившиеся за сутки».
Здесь практически вне конкуренции система Percona XtraBackup, которая содержит модифицированный движок InnoDB, анализирует двоичные логи MySQL и вытаскивает из них необходимую информацию. Почти такими же возможностями обладает платная InnoDB Hot Backup, упомянутая выше.
Общая проблема с любыми бэкапами в том, что они всегда отстают. В случае фатального сбоя основного сервера восстановить систему можно будет только с некоторым «откатом» по времени, что очень и очень разочарует её пользователей. Если в системе так или иначе были затронуты финансовые потоки, подобный «откат» может в прямом смысле влететь в копеечку.
4. Репликация
Избежать откатов призвана система репликации MySQL. Идея репликации основана на том, что кроме «главного» сервера («Мастера») постоянно работают ведомые сервера MySQL («слейвы»), которые получают инкрементные бэкапы с мастера в режиме реального времени. Таким образом, время отката уменьшается почти до сетевого лага. В случае краха Мастера можно оперативно назначить «новым Мастером» один из слейвов и перенаправить клиентов на него. Кроме того, слейвы могут обрабатывать запросы на чтение данных (SELECT-ы); это можно использовать для выполнения каких-то расчетов или снижения нагрузки на мастера. MySQL поддерживает репликацию «из коробки», процесс настройки репликации в MySQL хорошо описан юзером whisk. Существует возможность запуска конфигураций Master-Master, а с помощью внешних аппаратно-программных систем — и балансировки нагрузки между мастерами. Только не нужно забывать про ограничения, накладываемые CAP-теоремой.
Репликация — это очень здорово, только использовать её нужно по назначению. Реплика — это полная копия базы, но это не резервная копия! Очевидно же, что если на мастере выполнить DROP TABLE или UPDATE users SET password=«Haha!», изменения будут тут же скопированы на слейв, и откатить их назад станет невозможно.
Репликацию можно совместить с бэкапом на уровне файлов базы, останавливая слейв, а не мастера.
Всё пропало! Или нет? Часть I. Как сделать резервную копию сайта
Все платные хостинги автоматически делают резервное копирование файлов, которые содержат частичную или полную информацию о сайте. Это важно: если что-то случится с сайтом — всё можно будет вернуть. Да, автоматические бэкапы помогают, но лучше уметь делать это самостоятельно, чтобы не зависеть от обстоятельств. Сейчас мы вам всё расскажем.
Что такое бэкап сайта и зачем он нужен
Бэкап (от англ. backup — «резервная копия») — это резервная копия данных, которая содержит всю информацию о сайте от оформления до текстов и хранится на компьютере, сервере или в облачном хранилище. Эти данные нужны на случай, если что-то случится с основной версией.
В RU-CENTER мы делаем резервное копирование ежедневно и храним бэкапы в течение 7 дней, после чего они удаляются. Резервное копирование электронных писем не делаем, но вы можете настроить его в самом почтовом сервисе или перенаправлять письма на другую почту.
Если на сайте планируются технические работы, смена шаблона, сервера или хостинга — для перестраховки лучше самостоятельно сделать копию сайта и сохранить её на компьютере. Она пригодится, если захотите протестировать, например, работу сайта на новом хостинге.
Восстановление бэкапа поможет, если ваш сайт атаковали вирусы: вернувшись к чистой резервной копии, вы избавитесь от вредителей. Это также выручит, если вы захотите отменить изменения или случайно что-то удалите.
Словарь терминов
Составили для вас список терминов, которые будут встречаться в статье.
FTP (File Transfer Protocol) — это протокол, который используется для передачи файлов.
Доступ по FTP — это один из возможных способов доступа к файлам на сервере. Обычно используется для обновления информации на сайтах при помощи специальных FTP-клиентов, а также для доступа к какой-либо удалённой папке сервера, чтобы загружать и выгружать нужные вам файлы.
FTP-сервер — это любой сервер, который поддерживает FTP.
FTP-клиент — это программа для простого доступа к удалённому FTP-серверу. Может работать в режиме текстовой консоли, пересылая команды пользователя и файлы. Или же отображать файлы на удалённом сервере, как если бы они были на вашем компьютере. А может выполнять и оба сценария одновременно.
Панель управления хостингом — это программа с графическим интерфейсом, с помощью которой можно управлять сервером через интернет в визуальном режиме. Проще говоря, через неё вы получаете доступ к сайту.
SSH (Secure SHell) — это сетевой протокол, чтобы соединяться с удалённым сервером, выполнять на нём команды и загружать файлы. Ключевая особенность — шифрование передаваемой информации.
MySQL — система управления базами данных, которая работает с большой скоростью и устойчивостью и которую легко использовать.
Что важно учесть при резервном копировании
Во время копирования сайт может работать немного медленнее — не стоит заниматься этим в пик посещаемости.
По FTP чаще всего происходит заражение сайта — работайте в FTP-клиенте на защищённом от вирусов компьютере.
Подготовьте место для бэкапа файлов и дампа базы данных сайта — на компьютере, удалённом FTP-cервере или облачном хранилище (Dropbox, Google Drive, Облако Mail.ru и другие). Весить они будут почти столько же, сколько сам сайт (чуть меньше, но всё же).
Как сделать резервное копирование
Резервное копирование делается по-своему для файлов сайта и базы данных (дамп базы данных). В обоих случаях это можно сделать несколькими способами.
Резервное копирование файлов сайта
Можно сделать через панель управления хостингом, FTP-клиент FileZilla и SSH-доступ.
Через панель управления хостингом
Панель обычно идёт вместе с хостингом, отдельно её оплачивать не нужно. Во всех панелях управления есть инструмент для резервного копирования. Все примеры в этой статье — на панели управления виртуальным хостингом RU-CENTER.
Шаг 1. В панели управления хостингом зайдите в раздел «Резервные копии». Вы автоматически окажетесь во вкладке «Файлы» — она нам и нужна. Выберите подходящий день на календаре (1), в который делались резервные копии, и нажмите на название сайта (2).
Шаг 2. Нажмите на «Восстановить полностью», а в открывшемся окне — «Восстановить с сохранением». Копия файлов будет сохранена в каталоге /home/login/tmp/DATE, где DATE — дата и время резервного копирования, например, 202010210135.
Шаг 3. Чтобы скачать копию файлов сайта, зайдите в раздел «Файловый менеджер» на панели. Откройте папку tmp.
Шаг 4. Зайдите в папку от нужной даты (в примере — 202010210135). Поставьте галочку рядом с папкой с названием вашего сайта (скорее всего, она там единственная), нажмите на «Архиватор» и в появившемся меню выберите «Добавить в архив».
Шаг 5. В открывшемся окне введите название архива, например, «Бэкап_20201021». Нажмите на кнопку «Архивировать».
Шаг 6. Обновите страницу, и в списке появится архив с бэкапом в формате rar. Нажмите на него, чтобы скачать, — или поставьте галочку рядом с файлом и в появившемся меню нажмите на «Скачать».
Больше информации о работе с файловым менеджером в этой инструкции.
Через FTP-клиент FileZilla
Логин, пароль и адрес сервера для доступа по FTP найдёте в письме хостинг-провайдера, а также в панели управления. Зайдите в раздел «FTP и SSH», вы автоматически окажетесь во вкладке FTP.
Нажмите на FTP-пользователя, откроется страница с данными. Чтобы узнать пароль, нажмите на кнопку «Сбросить пароль» — и увидите его во всплывающем окне. Также вы можете получить его на почту, поставив галочку рядом с «Выслать пароль на почту» и нажав на ту же кнопку.
Шаг 1. Установите FileZilla. Скачайте программу на официальном сайте, нажав на кнопку Download FileZilla Client. Стандартной версии будет достаточно.
Шаг 2. Авторизуйтесь. Введите данные для доступа к сайту в верхней панели: хост (адрес сервера), имя пользователя и пароль. В поле «Порт» впишите «21» — это стандартный порт FTP.
Что делать, если при авторизации возникает ошибка «Невозможно подключиться к серверу»
1. Нажмите на кнопку в верхнем левом углу (1) для запуска «Менеджера сайтов». В разделе «Общие»:
2. Введите логин и пароль для доступа к сайту и нажмите «Ок». В открывшемся окне нажмите также «Ок».
После авторизации окно программы FileZilla станет выглядеть так:
Шаг 3. Создайте папку для бэкапа на своём компьютере. Назовите её так, чтобы вы смогли её потом опознать, например «Бэкап_Название сайта_Дата бэкапа». Откройте папку в левой части проводника FileZilla, выбрав в открывающемся меню или введя вручную (место расположения папки можно посмотреть в свойствах).
Шаг 4. Сделайте бэкап. Выберите файлы и папки сайта в правой части окна, кликните правой кнопкой мыши и нажмите «Скачать» — или перетяните их в левую часть проводника (там где созданная вами папка на компьютере). Программа начнёт копировать файлы — это займёт некоторое время.
Через SSH-доступ
Данные для подключения к серверу по SSH вы найдёте в разделе «FTP и SSH», вкладка SSH панели управления или в письме от хостинг-провайдера. Чтобы узнать пароль, нажмите на кнопку «Сбросить пароль» — и увидите его во всплывающем окне. Также вы можете получить его на почту, поставив галочку рядом с «Выслать пароль на почту» и нажав на ту же кнопку.
Это вариант для продвинутых пользователей или администраторов, которые знают, как работать с командной строкой. В большинстве случаев для бэкапа файлов сайта достаточно панели управления или FTP-клиента — их мы рассмотрели выше. А если хотите узнать больше о работе с хостингом по SSH — прочтите нашу инструкцию.
Резервное копирование базы данных
Через панель управления хостингом
Шаг 1. Зайдите в раздел «Резервные копии», вкладка «Базы данных». Выберите нужный вам день на календаре (1), в который делались резервные копии, и нажмите на «Резервная копия от (время)» (2).
Шаг 2. Нажмите на «Выберите операцию», далее «Сохранить в виде файла». Дамп базы данных сохранится в папке tmp и станет доступен для скачивания.
Шаг 3. Чтобы скачать дамп базы данных, зайдите в раздел «Файловый менеджер» на панели. Откройте папку tmp.
Шаг 4. Зайдите в папку от нужной даты и выберите из списка дамп базы данных login_db.sql. Нажмите на него, чтобы скачать, — или поставьте галочку рядом с файлом и в появившемся меню нажмите на «Скачать».
Через phpMyAdmin
Логин и адрес сервера для доступа к MySQL найдёте в письме от хостинг-провайдера, а также в панели управления хостингом в разделе «Базы данных». Перейдите во вкладку «Пользователи» и нажмите на имя пользователя.
Чтобы получить пароль, нажмите на кнопку «Сбросить пароль» — и увидите его во всплывающем окне. Также вы можете получить его на почту, поставив галочку рядом с «Выслать пароль на почту» и нажав на ту же кнопку. Если что, вот мини-инструкция для подключения к серверу MySQL.
Шаг 1. Откройте phpMyAdmin. Для этого зайдите в панель управления хостингом в раздел «Базы данных» и нажмите на PHPMyAdmin. В результате откроется окно авторизации.
Шаг 2. Авторизуйтесь. Окно станет выглядеть так:
Шаг 3. Слева на странице выберите нужную базу данных (1) и нажмите на вкладку «Экспорт» (2). Окно станет выглядеть так:
Через SSH-доступ
Данные для подключения к серверу по SSH вы найдёте в разделе «FTP и SSH», вкладка SSH панели управления или в письме от хостинг-провайдера. Чтобы узнать пароль, нажмите на кнопку «Сбросить пароль» — и увидите его во всплывающем окне. Также вы можете получить его на почту, поставив галочку рядом с «Выслать пароль на почту» и нажав на ту же кнопку.
Резервное копирование и восстановление баз данных SQL Server
В этой статье описаны преимущества резервного копирования баз данных SQL Server, основные условия резервного копирования и восстановления, а также приведены стратегии резервного копирования и восстановления для SQL Server и рассмотрены вопросы безопасности, связанные с резервным копированием и восстановлением в SQL Server.
В этой статье приводятся общие сведения о резервном копировании SQL Server. Конкретные действия по резервному копированию баз данных SQL Server см. в разделе Создание резервных копий.
В дополнение к локальному хранилищу для хранения резервных копий SQL Server поддерживает резервное копирование и восстановление из службы хранилища BLOB-объектов Azure. Дополнительные сведения см. в разделе Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure. Для файлов базы данных, сохраненных в службе хранилища больших двоичных объектов Microsoft Azure, SQL Server 2016 (13.x); предоставляет возможность использовать моментальные снимки Azure для практически мгновенного создания резервных копий и ускорения восстановления. Дополнительные сведения см. в разделе Резервные копии моментальных снимков файлов для файлов базы данных в Azure. Azure также предоставляет возможности резервного копирования корпоративного класса для SQL Server на виртуальных машинах Azure. Это полностью управляемое решение резервного копирования поддерживает группы доступности Always On, долгосрочное хранение, восстановление на определенный момент времени, а также централизованное управление и мониторинг. Дополнительную информацию см. в статье Azure Backup для SQL Server на виртуальных машинах Azure.
Зачем выполнять резервное копирование
При правильном создании резервных копий баз данных можно будет восстановить данные после многих видов сбоев, включая следующие:
Кроме того, резервные копии баз данных полезны и при выполнении повседневных административных задач, например для копирования баз данных с одного сервера на другой, настройки Группы доступности AlwaysOn или зеркального отображения баз данных и архивирования.
Глоссарий терминов, связанных с резервным копированием
создание резервных копий
Процесс создания резервной копии путем копирования записей данных из базы данных SQL Server или записей журнала из ее журнала транзакций.
резервная копия
Копия данных, которая может использоваться для восстановления данных в случае возникновения ошибки. Резервные копии баз данных также могут использоваться для восстановления копии базы данных в новом расположении.
устройство резервного копирования
Диск или ленточное устройство, на которые записываются резервные копии SQL Server для последующего восстановления. Резервные копии SQL Server можно также записать в службу хранилища BLOB-объектов Azure, а формат URL-адреса используется, чтобы указать назначение и имя файла резервной копии. Дополнительные сведения см. в разделе Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure.
носитель данных резервной копии
Одна магнитная лента или несколько или один файл на диске или несколько, в которые были записаны одна резервная копия или несколько.
резервное копирование данных
Резервная копия данных всей базы данных (резервная копия базы данных), части базы данных (частичная резервная копия) или набора файлов данных или файловых групп (резервная копия файлов).
резервное копирование базы данных
Резервная копия базы данных. Полные резервные копии базы данных отображают состояние всей базы данных на момент завершения резервного копирования. Разностные резервные копии базы данных содержат только изменения базы данных с момента последнего полного резервного копирования.
разностная резервная копия
Резервная копия данных, основанная на последней полной или частичной резервной копии базы данных или набора файлов данных или файловых групп (базовой копии для разностного копирования), которая содержит только данные, измененные по сравнению с базовой копией для разностного копирования.
полная резервная копия
Резервная копия, которая содержит все данные заданной базы данных или наборов файлов или файловых групп, а также журналов для обеспечения возможности последующего восстановления этих данных.
резервная копия журналов
Резервная копия журналов транзакций, включающая все записи журнала, не входившие в предыдущую резервную копию журналов. (модель полного восстановления)
recover
Для возврата базы данных в стабильное и согласованное состояние.
recovery
Фаза запуска или восстановления базы данных, которая приводит базу данных в состояние согласованности транзакций.
модель восстановления
Свойство базы данных, с помощью которого выполняется управление обслуживанием журналов транзакций в базе данных. Существует три модели восстановления: простая модель восстановления, модель полного восстановления и модель восстановления с неполным протоколированием. Модель восстановления базы данных определяет требования к резервному копированию и восстановлению.
восстановление
Многоэтапный процесс, в ходе которого все данные и страницы журнала копируются из указанной резервной копии SQL Server в определенную базу данных, а затем выполняется накат всех фиксированных транзакций, записанных в резервной копии журнала, путем внесения новых данных на основе зарегистрированных изменений.
Стратегии резервного копирования и восстановления
Операции резервирования и восстановления данных следует адаптировать под конкретную среду с учетом доступных ресурсов. Таким образом, для надежного использования резервного копирования и восстановления требуется стратегия резервного копирования и восстановления. Хорошо спроектированная стратегия резервного копирования и восстановления позволяет сбалансировать бизнес-требования для обеспечения максимальной доступности данных и минимальной потери данных, учитывая стоимость обслуживания и хранения резервных копий.
Стратегия резервирования и восстановления состоит из части, относящейся к резервированию, и части, относящейся к восстановлению. Часть, относящаяся к резервированию, определяет тип и частоту создания резервных копий, тип и скоростные характеристики оборудования, необходимого для их создания, способ проверки резервных копий, а также местонахождение и тип носителя резервных копий (включая и вопросы безопасности). Часть, относящаяся к восстановлению, определяет ответственного за проведение операций восстановления, методы их проведения, позволяющие удовлетворить требования пользователей по доступности базы данных и минимизации потерь данных, а также методы проверки восстановления.
Разработка эффективной стратегии резервирования и восстановления требует тщательного планирования, реализации и тестирования. Проверка необходима — у вас нет стратегии резервного копирования до тех пор, пока не были успешно восстановлены все резервные копии во всех сочетаниях, включенных в стратегию восстановления, и не была проверена физическая согласованность восстановленной базы данных. Необходимо оценить ряд факторов. К ним относятся следующие объекты.
Задачи организации, относящиеся к рабочей базе данных, особенно требования к доступности данных и их защите от потери или повреждения.
Свойства каждой базы данных: размер, типичное использование, характер содержимого, требования к данным и т. д.
Ограничения на ресурсы, например: оборудование, персонал, пространство для хранения носителей резервных копий, физическая безопасность этих носителей и так далее.
Рекомендации
Использование отдельного хранилища
Убедитесь, что резервные копии базы данных размещаются в отдельном от файлов базы данных физическом хранилище или устройстве. Если физический диск, на котором хранятся базы данных, неисправен или завершается сбоем, восстановление зависит от возможности доступа к отдельному диску или удаленному устройству, в котором хранятся резервные копии. Помните, что можно создать несколько логических томов или разделов одного и того же физического диска. Прежде чем выбирать место хранения резервных копий, внимательно изучите разделы диска и структуры логических томов.
Выбор подходящей модели восстановления
Операции резервного копирования и восстановления выполняются в контексте модели восстановления. Модель восстановления является свойством базы данных, которое задает, как выполняется управление журналом транзакций. Таким образом, модель восстановления базы данных определяет, какие типы резервных копий и сценарии восстановления поддерживаются для базы данных и каким будет размер резервных копий журнала транзакций. Обычно база данных использует простую модель восстановления или модель полного восстановления. Модель полного восстановления может быть дополнена путем переключения на модель с неполным протоколированием перед выполнением массовых операций. Основные сведения о моделях восстановления и их влиянии на управление журналом транзакций см. в разделе Журнал транзакций (SQL Server).
Лучший выбор модели восстановления базы данных зависит от бизнес-требований. Чтобы избежать управления журналом транзакций и упростить резервное копирование и восстановление, используйте простую модель восстановления. Чтобы снизить вероятность потери результатов работы ценой увеличения административных издержек, используйте модель полного восстановления. Чтобы уменьшить влияние на размер журнала во время операций с неполным протоколированием и при этом обеспечить возможность восстановления этих операций, используйте модель восстановления с неполным протоколированием. Дополнительные сведения о влиянии моделей восстановления на создание резервных копий и восстановление см. в разделе Общие сведения о резервном копировании (SQL Server).
Создание стратегии резервного копирования
После того как выбрана модель восстановления, соответствующая бизнес-требованиям определенной базы данных, необходимо спланировать и выполнить соответствующую стратегию резервного копирования. Оптимальная стратегия зависит от многих факторов, среди которых наиболее важны следующие.
Сколько часов в день приложения имеют доступ к базе данных?
Если существует прогнозируемый внепиковый период, рекомендуется запланировать полное резервное копирование базы данных именно на этот период.
Насколько часты и вероятны изменения и обновления?
Если изменения часты, учтите следующее.
В рамках простой модели восстановления рассмотрите возможность запланировать разностное резервное копирование между полными резервными копированиями базы данных. Разностная резервная копия сохраняет только те изменения, которые были внесены с момента последнего полного резервного копирования.
В рамках модели полного восстановления следует запланировать частное резервное копирование журналов. Планирование разностного резервного копирования между полными резервными копиями сокращает время восстановления путем сокращения количества резервных копий журналов, которые необходимо восстанавливать после восстановления данных.
Касаются ли обычно изменения небольшой или же значительной части базы данных?
В большой базе данных, в которой изменения концентрируются в части файлов или файловых групп, полезно частичное резервное копирование или резервное копирование файлов. Дополнительные сведения см. в разделах Частичные резервные копии (SQL Server) и Полные резервные копии файлов (SQL Server).
Сколько места на диске требуется для полного резервного копирования базы данных?
За какой прошлый период компании нужны резервные копии?
Убедитесь, что установлен правильный график резервного копирования в соответствии с потребностями приложения и бизнес-требованиями. По мере устаревания резервных копий риск потери данных выше, если нет способа повторного создания всех данных до точки сбоя. Прежде чем удалять старые резервные копии из-за ограничений ресурсов хранилища, следует учесть, требуется ли возможность восстановления за этот период.
Оценка размера полной резервной копии базы данных
Создание расписания резервного копирования
Влияние, оказываемое осуществлением резервного копирования на выполняемые транзакции, минимально, поэтому операции резервного копирования могут выполняться одновременно с выполнением обычных операций. Резервное копирование в SQL Server можно выполнять с минимальным влиянием на рабочие нагрузки.
Сведения об ограничениях параллелизма во время резервного копирования см. в разделе Общие сведения о резервном копировании (SQL Server).
После принятия решения о том, какой тип резервного копирования необходим и как часто его выполнять, рекомендуется запланировать регулярное резервное копирование как часть плана обслуживания базы данных. Дополнительные сведения о планах обслуживания и об их создании для резервных копий баз данных и журналов см. в разделе Use the Maintenance Plan Wizard.
Тестирование резервных копий
Можно сказать, что стратегия восстановления отсутствует, пока резервные копии не протестированы. Очень важно полностью протестировать стратегию резервного копирования для каждой базы данных, восстанавливая копию базы данных в систему тестирования. Необходимо протестировать восстановление каждого типа резервной копии, которую планируется использовать. Также рекомендуется после восстановления резервной копии выполнить проверку согласованности базы данных с помощью инструкции DBCC CHECKDB базы данных, чтобы убедиться, что носитель резервной копии не поврежден.
Проверка стабильности и согласованности носителя
Используйте параметры проверки, предоставляемые служебными программами резервного копирования (команда T-SQL BACKUP, планы обслуживания SQL Server, программное обеспечение или решение для резервного копирования и т. д.). Пример см. в разделе [RESTORE VERIFYONLY] (../t-sql/statements/restore-statements-verifyonly-transact-sql.md) Используйте дополнительные функции, например BACKUP CHECKSUM, чтобы выявить проблемы с самим носителем резервного копирования. Дополнительные сведения см. в статье Возможные ошибки носителей во время резервного копирования и восстановления (SQL Server)
Стратегия резервного копирования и восстановления документов
Рекомендуется документировать процедуры резервирования и восстановления и хранить копию этой документации в документации по задаче. Также рекомендуется вести руководство по эксплуатации для каждой базы данных. Такое руководство по эксплуатации должно указывать расположение резервных копий, имена устройств резервного копирования (если есть), время, требуемое для восстановления тестовой резервной копии.
Отслеживание хода выполнения с помощью xEvent
Операции резервного копирования и восстановления могут выполняться в течение длительного времени из-за размера базы данных и сложности выполняемых операций. При возникновении проблемы с любой из операций можно использовать расширенное событие backup_restore_progress_trace для отслеживания хода выполнения в реальном времени. Дополнительные сведения о расширенных событиях см. в разделе Расширенные события.
С помощью расширенных событий backup_restore_progress_trace можно повысить производительность и существенно сэкономить дисковое пространство. Используйте эти события в течение короткого периода времени, проявляйте внимание и тщательно проверяйте свои изменения перед их реализацией в рабочей среде.