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