Каков ваш план резервного копирования и обслуживания SQL Server?

Question

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

В настоящее время я работаю с двумя планами техобслуживания в стиле джейн от мастера планов.

Первый работает ночью и делает почти все ...

• Полная резервная копия базы данных и журнала транзакций
• проверка целостности, перестроение индекса, пересчет статистики и т. Д. (Я проверил все, кроме инкрементного резервного копирования)

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

Резервные копии на диск, полные резервные копии отправляются в SAN, сохраняются в течение недели.

Как вы думаете, это разумный план? Есть предложения?

РЕДАКТИРОВАТЬ: это SQL Server 2005. БД 5 ГБ, увеличивается примерно на 1 ГБ / месяц.

Answer 1

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

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

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

Answer 2

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

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

Answer 3

Я не думаю, что вы параноик, запуская резервные копии каждые 3 часа. По сути, ваш план резервного копирования должен измеряться вашими требованиями к восстановлению. Как долго вы можете позволить себе потерять работоспособность, пока вы восстанавливаетесь, и сколько данных вы готовы потерять до того, как закончите работу. Для SQL Server вы можете значительно сократить объем данных, которые вы готовы потерять, добавив резервные копии журналов транзакций в свой план резервного копирования. Многие люди делают это каждые несколько минут в зависимости от количества транзакций, проходящих через систему. Чтобы выполнить восстановление, достаточно просто восстановить последнее полное, последнее приращение, а затем все резервные копии журнала транзакций, начиная с приращения. Это может дать вам минимальную потерю данных, но может потребоваться немного времени, чтобы применить все резервные копии журнала транзакций. Я регулярно вижу следующее: Полные резервные копии - еженедельно Инкрементные резервные копии - ночные Резервное копирование журнала - каждые несколько минут в зависимости от требований (может быть полезно раз в час и т. Д.)

Answer 4

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

Answer 5

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

Answer 6

На мой взгляд, лучший способ это:

Полное резервное копирование базы данных каждые 12 часов

BACKUP DATABASE database TO DISK = 'd:/full.bak'

разностное резервное копирование каждые шесть часов, в случае сбоя процесс восстановления проще

BACKUP DATABASE database TO DISK = 'd:/diff.bak' WITH DIFFERENTIAL

и, конечно, резервные копии журнала транзакций, которые лучше делать каждый час.

BACKUP LOG database TO DISK = 'log.bak'

В случае сбоя процесс восстановления будет следующим:

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

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