SQL Server 2005: правильное расписание резервного копирования
Я разработчик.NET, и я знаю, как писать SQL, но не знаю, как выполнять планирование обслуживания баз данных.
Итак, я недавно принял проект от предыдущего клиента. Сайт размещен на Rackspace.
В любом случае предыдущий клиент делал три полных резервных копии ежедневно (каждые 8 часов). Мне просто любопытно, каков надлежащий стандарт?
У меня есть несколько вопросов.
Я добавляю или перезаписываю?
Я устанавливаю ежедневные резервные копии, чтобы истечь? [Rackspace делает ежедневный дифференциал и еженедельный полный, я верю также]
Нужно ли делать резервную копию журнала транзакций?
Нужно ли сжимать журнал транзакций?
Пожалуйста, поделитесь некоторыми идеями, лучшими практиками. Они будут очень признательны!
Спасибо!!
3 ответа
Я добавляю или перезаписываю?
Если он будет записан на пленку позже, я перезапишу, в противном случае выберут приемлемый таймфрейм на диске для срока действия резервных копий (в зависимости от времени восстановления) и добавьте.
Я устанавливаю ежедневные резервные копии, чтобы истечь? [Rackspace делает ежедневный дифференциал и еженедельный полный, я верю также
Да, если дисковое пространство не является проблемой
Нужно ли делать резервную копию журнала транзакций?
Да, так часто, как вам требуется для восстановления на определенный момент времени. например, если ваше соглашение об уровне обслуживания говорит, что вы потеряете только 15 минут данных в случае сбоя, вам необходимо выполнять резервное копирование журнала транзакций каждые 15 минут.
Нужно ли сжимать журнал транзакций?
Нет, если вы как-то не позволили ему расти до огромного размера в одной точке, и теперь он никогда не использует больше 1%, и у вас мало места на диске, тогда, возможно,
Пожалуйста, поделитесь некоторыми идеями, лучшими практиками. Они будут с благодарностью
Вам необходимо поработать с бизнесом, чтобы определить, какой тип данных они ожидают потерять в случае возникновения проблемы, и как долго это приведет к недоступности БД. Как только у вас есть соглашения о тех, кто на месте, все остальное становится математическим упражнением. В вашем примере вы упоминаете, что вы делаете 3 полных в день. Вам нужно выяснить, если это просто кто-то выстрелил в темноте или есть причина, по которой это 3 дня (возможно, из-за увеличения времени восстановления это невозможно)
Обратите внимание, что только после того, как вы получите бизнес-требования, вы сможете планировать восстановление. Мантра "планируйте свое восстановление" настолько злоупотреблена, что многие администраторы действительно верят в это и просто делают те же самые ошибки, которые они допустили бы, если бы просто беспокоились о резервном копировании.
На самом деле не существует "надлежащего стандарта", поскольку речь идет о:
Сколько данных вы можете позволить себе потерять?
Достаточно стандартизированная резервная копия должна сделать что-то вроде этого:
- Полное резервное копирование каждую неделю (или 2-3 раза в неделю)
- Разностные резервные копии каждый день (или несколько раз в день)
- Вторичный сервер с внедренной доставкой журналов
Очевидно, это зависит от того, как выглядит ваша нагрузка, сколько дискового пространства у вас есть для резервного копирования и т. Д.
Исходя из предоставленной вами информации, я не думаю, что три полных резервных копии в день необходимы. Вы можете легко получить одну полную резервную копию в день, а затем столько разностных резервных копий, сколько считаете нужным.
РЕАЛЬНЫЙ ключ к резервному копированию - это не планирование ваших резервных копий, а планирование вашей процедуры восстановления.
Если вы начнете с конца... и процесса восстановления и максимального объема данных, который вы можете потерять (или захотите потерять), вы найдете план резервного копирования, который подходит вам.
В моем магазине я запускаю резервные копии t-log каждый час. Мои разногласия запускаются каждую ночь, а полные резервные копии - по воскресеньям У меня нет настроек резервного копирования для автоматического истечения срока действия. Я удаляю их вручную, когда они больше не нужны. Я еще не реализовал доставку журналов, поскольку у меня нет доступных ресурсов... пока.