База данных в любой организации – незаменимое средство для хранения больших массивов информации. К потере важных записей может привести любое механическое или системное повреждение компьютеров, используемых для хранения и работы. Правильное и своевременное резервное копирование базы данных SQL – верный способ уберечь систему от потерь. Несмотря на тот факт, что производители компьютерного железа, а также разработчики соответствующего ПО делают все возможное для защиты пользовательских материалов, непреднамеренные удаление или сбои – распространенное явление.
Если бэкап актуальной версии заблаговременно сформирован и сохранен, то администратор или рядовой сотрудник может за несколько минут выполнить работу по восстановлению и продолжить использование SQL-БД. Без бэкапирования, разумеется, утерянные сведения навсегда останутся в истории. Не исключаются серьезные проблемы как для работников, допустивших такую оплошность, так и для целой организации, которая в один момент лишится целого массива информации.
Сегодня присутствует множество средств для резервного архивирования как целых БД, так и отдельных элементов. Помимо ряда встроенных средств и утилит пользователям доступны средства от сторонних разработчиков. Поскольку СУБД на MS SQL – одни из самых распространенных, подобрать качественное ПО от проверенных создателей можно без особых сложностей и с минимальным бюджетом. Мы же в этом обзоре рассмотрим стандартные методики, которых при правильном подходе более чем достаточно для сохранности информации.
Модели восстановления
В дальнейшем довольно часто будут фигурировать разные формы реконструирования и управления потерянным из Backup. Всего таких SQL-моделей три, и они имеют существенные различия. Рассмотрим свойства каждой из них подробнее.
- Простая (SIMPLE)
Отсутствует возможность копирования журналов транзакций или отдельных разделов из них. Это одновременно является как преимуществом, так и недостатком. Плюс – на слабых серверных машинах с малыми жесткими дисками отпадает надобность в дополнительной очистке или модификации оборудования. Минус – любые изменения, внесенные после создания бэкапов, не будут отражены в архивных документах, соответственно их придется восстанавливать вручную. Рекомендовать это решение можно исключительно для случаев, когда присутствует гарантия от возникновения ситуаций, связанных с критическими неисправностями. Выбирая такой вид желательно приготовиться к необходимости организации репликации в бэкап-архивы как можно чаще. Миграция на следующую модель возможна, однако рекомендуется создавать бэкап с нуля для того, чтобы избежать ошибок.
- Полная (FULL)
В отличии от вышеописанной технологии, в полной все ЖТ и логи резервируются постоянно. За счет этого пользователи после потери и выполнения восстановительной операции могут вернуться к моменту, на котором остановились до аварийной ситуации. Помимо этого, возвращаться можно практически на любой момент, связанный с внесением изменений. Это привносит дополнительное удобство при введении поправок в тестовом режиме. Также откатиться можно при возникновении ошибок из-за неправильно внесенной информации. Учитывая потребность в полном сохранении SQL-журналов, могут потребоваться довольно серьезные объемы памяти. Проблема почти полностью решается за счет применения удаленных облачных систем хранения при наличии должной защиты.
- С неполным протоколированием (BULK_LOGGED)
Работает по схожему с Full алгоритму, однако протоколируются журналы не полностью. Это помогает экономить пространство на устройствах хранения, но есть вероятность необходимости ручного воссоздания потерянных элементов если сбой в работе произошел после выполнения задач, подразумевающих частичное протоколирование.
Верным выбором для сохранности всех записей, а также настроек, является Full-модель. Применяя ее можно восстановить с нуля как полностью БД, так и отдельные ее сегменты без потери каких-либо важных файлов. Если же мощности серверного оборудования не позволяют полноценно сохранять массивы с данными для аварийного реконструирования, то останавливаться стоит на Simple-модели с индивидуальным графиком резервирования.
Нюансы создания бэкапов
Первостепенной задачей администратора или иного сотрудника, ответственного за СУБД, является проработка стратегии резервного дублирования на основе используемой в организации модели и индивидуальных факторов. Упростить разработку поможет составление чек-листа, в основе которого будут лежать ответы на следующие вопросы:
- Насколько часто (часов в сутки, дней в месяц) рабочие программы взаимодействуют с общей SQL-базой, которая будет подвергаться бэкапированию?
-
- если присутствуют внепиковые периоды, которые можно спрогнозировать заранее, то рассматриваемые процедуры имеет смысл проводить именно тогда.
- Какова частота внесения изменений или обновлений?
- при внедрении simple-модели надо рассмотреть возможности, предоставляемые в рамках разностного сохранения, выполняемого в промежутках между основным дублированием, такой подход даст возможность возвращаться к промежуточным этапам при возникновении неполадок;
- при выборе full-модели также актуально разностное копирование, ведь с его помощью можно достаточно серьезно сократить затрачиваемое на восстановительные операции время (достигается за счет уменьшения количества малоэффективных записей в журналах).
- Вносимые при работе сотрудников изменения затрагивают БД целиком или частично?
- если общий файловый массив в течение долгого времени остается неизменным, а какие-либо коррективы вносятся в небольшие сегменты, то имеет смысл пользоваться услугой создания частичной копии для достижения хорошей экономии ресурсов.
- Какую часть хранилища можно выделить для сохранения бэкап-файлов?
На последнем вопросе мы остановимся более внимательно, ведь правильное распределение места на физических и виртуальных носителях – залог избавления от лишних финансовых затрат. Ранее мы определились с тем, что наиболее объемные бэкапы выходят вследствие выполнения full-модели или совмещения простой с неполным ведением протокола. При этом надо понимать, что размер бэкапа всегда будет меньше. Связано это с архивированием только рабочих материалов и надстроек, а не всего пространства. Для вычисления необходимого объема советуется применять “sp_spaceused” в среде Transact-SQL.
Расписания и проверки
При проведении манипуляций с SQL-базами, как и в остальных случаях, частота играет серьезную роль. Предлагаемые Microsoft средства автоматизации избавляют от необходимости уделять лишнее время манипуляциям с утилитами, создающими архивы. Примечательной особенностью считается концепция параллелизма, позволяющая решать большую часть задач вместе с архивированием без чрезмерной нагрузки мощностей.
Полноценно доступны инструкции INSERT, UPDATE и DELETE. Однако, не исключается образование конфликтов. Алгоритм их решения можно рассмотреть на примере удаления какой-либо информационной ячейки или раздела: процедуры исполняются в режиме классической очередности – пока не завершится действие, начатое ранее, следующее будет находиться в режиме ожидания. Для того, чтобы предотвратить дополнительные сложности, стоит мониторить запущенные процессы в системе.
При бэкапировании с SSMS периодичность исполнения соответствующих заданий указывается в плане обслуживания SQL-базы. При средних нагрузках целесообразно еженедельное архивирование.
Полноценной разрабатываемую стратегию можно считать исключительно после тестирования бэкап-файлов. Разумеется, это действие как по времени, так и по ресурсам. Но получить гарантию сохранности всего заархивированного можно лишь при проведении проверки. При выявлении поврежденных участков решение о полной или частичной перезаписи принимается индивидуально.
Утилита в SQL Server Management Studio
Наиболее доступным, практичным и безопасным подходом считается использование набора надстроек, встроенных в основной продукт. Производитель учитывает все нюансы и риски, поэтому подключение дополнительного ПО от сторонних разработчиков – необязательно. Если же есть острая надобность в обеспечении максимальной сохранности всего, что включено в SQL-СУБД, то приобретение вспомогательных компонентов целесообразно. Пошаговая инструкция по классическому бэкапированию состоит из следующих шагов:
- Находим в списке установленных программ утилиту для менеджмента SQL-системы и запускаем ее.
- Заполняем все нужные для авторизации пункты, выбираем сервер и производим соединение.
- В правой части окна расположено меню “Обозреватель объектов”, в котором находится список каталогов, существующих в сети (или на жестком диске). Определяем нужную папку для бэкапирования и через нажатие правой кнопки мыши переходим в раздел “Задачи”, далее – “Создать резервную копию”.
- Ожидаем запуска соответствующей подпрограммы и выполняем ряд обязательных манипуляций:
- проверяем, верная ли SQL-БД выбрана;
- подбираем модель, которую определили ранее;
- задаем имя (обязательно) и описание (необязательно);
- вводим месторасположение папки, в которой будут создаваться backup-файлы, также на этом этапе возможно подключение сторонних аксессуаров – карт памяти или USB-дисков с достаточным количеством свободной памяти;
- во вкладке “Параметры” можно активировать проверку по завершению бэкапирования, а также указать на действия, которые автоматически будут выполняться при появлении ошибок.
- Подтверждаем все настройки и запускаем процесс. После получения оповещения о завершении проверяем наличие bak-файла в заданной директории.
Как наладить функционирование после аварии?
Для извлечение всего сохраненного в bak-архиве нужно запустить SQL-Management-Studio и проделать все манипуляции по авторизации в необходимой среде. Далее, как и в предыдущей инструкции, ищется нужная SQL-база и через контекстное меню вызывается подпрограмма “Восстановить”. Далее необходимо проверить правильность выбранной СУБД и указать локацию на встроенном, подключаемом или удаленном хранилище. Предварительно стоит убедиться в наличии bak-файла и дате его записи. Если все в порядке – запускаем задание и ожидаем оповещения о завершении.
В целях безопасности следует избегать использования bak-файлов, полученных из неизвестных источников. Не исключается наличие в них ошибок или вредоносных записей, которые при активации причинят непоправимый вред. Желательно пользоваться штатным защитником Windows или подключать антивирусы с актуальными обновлениями. Эти рекомендации применимы при миграции с одной машины на другую.
