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

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

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

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

Когда выполнять восстановление

Когда вы восстанавливаете код (хранимые процедуры, представления, триггеры и т. д.) или отдельные таблицы, не восстанавливайте их на рабочем сервере. Мне не нравится иметь дело с производственными серверами чаще, чем это необходимо, и давайте посмотрим правде в глаза - у вас и так достаточно плохой день. Вы же помните, почему вы делаете восстановление, не так ли? Поэтому давайте сделаем нашу работу на другом сервере (например, dev или QA) и оставим производство без изменений. Я также написал о восстановлении в моей идеальной среде разработки, тестирования и производства.

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

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

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

Это может потребовать дополнительного места на рабочем сервере. В одном случае я освободил необходимое пространство, сократив все данные и файлы журнала TempDB до 1 Мб. TempDB был на быстрых дисках, идеально подходящих для однократного аварийного восстановления, и на этом конкретном сервере не происходило никаких других действий из-за сбоя. Нам не всегда так везет, но это помогает мыслить нестандартно.

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

Выполнение восстановления

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

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

Затем, если задействованы дифференциальные резервные копии, восстановите самый последний дифференциал WITH NORECOVERY. Дифференциальное резервное копирование накопительное - вам нужно восстановить только самое последнее.

Затем восстановите все резервные копии журналов транзакций после дифференциала (или, если у вас нет различий, все после полной резервной копии) - снова, используя WITH NORECOVERY.

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

No Comments