Назад | Перейти на главную страницу

Стратегии резервного копирования базы данных SQL Server в реальном времени

Я пытаюсь придумать стратегию резервного копирования для SQL Server 2005. Я думаю о выполнении полного резервного копирования раз в неделю, дифференциального резервного копирования раз в день и резервного копирования журнала транзакций каждые 15 минут. Размер базы данных составляет около 50 ГБ. Дело в том, что база данных работает ежесекундно. Будет ли полная резервная копия мешать работе? Нужно ли мне что-то делать, чтобы резервное копирование проходило гладко без приостановки каких-либо операций с базой данных?

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

Бэкапы работают отлично. Без прерывания базы данных. Очевидно, что вы увидите более высокую нагрузку на ввод-вывод, поскольку производительность резервного копирования io повышается над вводом-выводом диска.

К тому же требования к памяти выше, чем без резервных копий - очевидно.

Я могу только повторить joeqwerty. Для серьезного бизнес-приложения, где действительно важны доступность и время простоя, вы иметь начать с вопроса «Каковы бизнес-требования к доступности и целостности данных» и двигаться дальше.

Не думай только о резервное копирование, подумай о восстановить.

Сколько времени потребуется, чтобы восстановить БД до последнего заведомо исправного состояния, используя предложенную вами схему? Вы знаете? Приемлем ли такой срок для бизнеса?

Что компания может себе позволить в этой области и позволяет ли это удовлетворить их потребности?

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

При резервном копировании сервера sql не будет «паузы» в работе базы данных, но это не означает, что производительность не пострадает. Лучшая практика для этого ИМХО - настроить отдельный диск только для резервного копирования, отдельного для ваших данных и диска журнала.