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

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

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

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

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

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

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

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

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

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

Делайте полную резервную копию базы данных каждые 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'

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

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

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