DBA там,
У нас есть среда SQL, которая требует обновления решения для резервного копирования, и мы ждем некоторых отзывов от сообщества. 8 ДБ распределены по 4 серверам общим размером 100 ГБ, плюс 9-я БД размером 450 ГБ, которая не указана в числах ниже. Все они расположены в центре обработки данных с большой пропускной способностью (OC-3).
В настоящее время резервное копирование выполняется из планов обслуживания SQL Management Studio в массив в центре обработки данных с базами данных. Резервное копирование вне офиса выполняется сотрудником, который еженедельно подключает USB-накопитель, копирует данные и забирает этот накопитель обратно в офис. В идеале мы хотели бы убрать аспект того, что человек должен заходить в центр обработки данных, чтобы получить данные.
В настоящее время резервные копии заполняются ежедневно. Облегченная скорость доступна для сжатия, и мы могли бы продолжать запускать ежедневные полные файлы для удобства, или мы могли бы перейти к смеси из 1 полных 3-дневных переполнений плюс транс для некоторых БД и 1 полных 6-дневных переполнений плюс транс для других. БД, а не все полные. Есть мысли по этому поводу?
Одним из вариантов вне площадки является использование DFS или другого механизма копирования для синхронизации общей резервной копии центра обработки данных с общей папкой в офисе / за пределами площадки через T1 в ночное время. При вычислении чисел, если мы перейдем к плану сравнения, мы смотрим на ~ 6 ГБ в большинстве случаев и ~ 19 ГБ в субботу вечером для резервного копирования данных. Если бы для процесса синхронизации был доступен полный T1, это было бы 9 часов в большинстве ночей и 27 часов в субботу.
Другой вариант - приобрести устройство с подпиской на резервное копирование за пределами площадки для отправки данных из удаленного местоположения в сторонний центр обработки данных, но мы можем рассчитывать на высокую стоимость.
Это примерно 59,5 ГБ данных в неделю, поэтому, если мы хотим хранить 2 месяца, это примерно 0,5 ТБ.
Есть предположения?
Заранее спасибо!
Определенно пойдет с дифференциальным резервным копированием и, если вам это удастся, раз в месяц полные резервные копии, которые переносятся вручную, если окно резервного копирования не позволяет в это время скопировать их.
"KISS" Будьте проще.
Я думаю, все зависит от того, сколько денег вы можете потратить и какой тип удержания вам нужен. У нашей группы инфраструктуры есть сеть хранения данных с доступными нам ТБ хранилища. У нас есть общий сетевой ресурс для папки в SAN, в которую мы записываем все наши резервные копии SQL. У нас более 15 SQL-серверов и 150+ баз данных. У меня есть 1 план обслуживания для каждой базы данных для полного резервного копирования (ежедневно, в нерабочее время) и 1 план для журналов транзакций (каждые 15 минут). Оба плана удаляют файлы старше 24 часов, чтобы хранилище резервных копий было в чистоте. Это дает мне доступ к данным за несколько дней в случае возникновения каких-либо проблем. Резервные копии затем копируются на ленту каждую ночь. Их можно хранить столько, сколько нам нужно. Нашему сейчас 3 месяца.
Я определенно согласен, что вам нужно убрать человеческий аспект, как вы сказали. В идеале вообще не нужно прикасаться ни к чему из этого (кроме, может быть, лент).
Мне лично не нравятся варианты за пределами площадки, поскольку я могу по крайней мере пойти и вставить кассету в себя, если потребуется. Я знаю, что у вас есть с ними договор на обслуживание, но все же ...
Надеюсь, это поможет дать вам несколько идей.
Для восстановления смеси fulls / diffs / t-logs намного лучше. Потеря данных будет меньше, так как в лучшем случае с t-log вы потеряете час данных вместо целых дней. Как я читал ранее, причина, по которой люди делают резервные копии, - это восстановление.
Каждую неделю мы делаем две полных и 4 инкрементальных (в воскресенье в нашей системе почти ничего не происходит, так что это хорошее время для очистки). 1 полный хранится на месте, и мы настроили его для вращения лент (у нас есть очень хорошая ленточная библиотека, в которую загружены 23 ленты и 1 чистящая лента)
1 полный отправляется за пределы площадки. Первый полный месяц отправляется в сейф, остальные идут к продавцу, Iron Mountain, который действительно приходит сюда и забирает их.
Общий объем наших резервных копий составляет около 1,2 ТБ для полных и 140 ГБ для дополнительных. Использование дифференциалов нам очень помогает, потому что заполнение занимает почти 22 часа, а делать это каждый день было нелепо. Мы используем Backup Exec 11d с ленточной библиотекой HP MSL G3.
Пятый пост - я согласен почти со всем, что было опубликовано, и не буду его повторять.
Когда делать полное / дифференциальное / TransactionLog резервное копирование, зависит от того, что и когда делают ваши системы. Часто это хорошо работает с недельным циклом, поскольку один день обычно бывает выходным (воскресенье или, может быть, понедельник, когда вы убираетесь после работы на выходных). Я бы рекомендовал выполнять резервное копирование не реже чем раз в неделю; Если эта резервная копия выходит из строя, вам придется вернуться к предыдущей, и потеря данных за две недели не так страшна, как потеря данных за два месяца. (И всегда есть что-то ... другой отдел. В том месте, где я работал, сразу же возникла ситуация «нет действительной полной резервной копии БД на несколько месяцев» [потому что они не делали их, но это другая история]. После восстановления нескольких недель из резервных копий t-log они обнаружили поврежденную, и пришлось действовать по плану Б: выкопать документы и повторно ввести результаты работы всего за несколько месяцев.)
Если воскресенье - медленный день, делаю переиндексацию, еженедельные архивы и т. Д. перед еженедельное полное резервное копирование - хорошая идея, чтобы вся эта хлопотная работа не загружалась в резервную копию различий. (Меня устраивает еженедельное полное резервное копирование, но, как всегда, многое зависит от вашего бизнеса и моделей использования данных.)
Похоже, копирование данных через сеть в домашний офис не очень практично. Что происходит, когда объем данных превышает ваши возможности скопировать за одну ночь?
Резервное копирование на ленту - это хорошо и довольно легко автоматизируется (хотя и стоит денег). Также хороши услуги хранения вне офиса; они стоят денег, но, поскольку они все равно должны навестить вас, может быть, вы сможете заставить их попасть в серверную? (Зависит от безопасности, доступа и т. Д. И т. Д.)
Лично я предпочитаю делать полные резервные копии на ежедневной основе и хранить на диске три поколения - я не склонен использовать сочетание полного / дифференциального из-за риска того, что полная резервная копия не будет успешно восстановлена. Я понимаю, что это сложно, если у вас большие базы данных, но в наши дни 100 ГБ не так уж и много.
Убедитесь, что у вас установлена последняя версия LiteSpeed и используется самый высокий уровень сжатия (если пользователи не имеют доступа к системе одновременно с запуском резервного копирования).
Рассмотрите возможность удаления любых избыточных таблиц.
Проверьте и удалите неиспользуемые индексы.
Удалите фрагментацию из ваших таблиц и индексов.
Рассмотрите возможность архивирования старых данных в другую базу данных и реже создавайте резервные копии.
Это зависит от вашего бюджета, но моя компания только что перешла с ленты на систему на основе SAN с функцией дедупликации с зеркалом во втором центре обработки данных - и мне это нравится. Полностью качает.
У меня есть любые небольшие БД, настроенные с полными сжатыми резервными копиями каждую ночь, и большие с двойным или раз в неделю полными и ночными изменениями, все на локальные диски для облегчения восстановления. Критически важные компоненты добавляют резервные копии журналов транзакций и доставку журналов на удаленный SQL-сервер горячего переключения.
Из файлов на локальном диске программное обеспечение автоматического резервного копирования на магнитную ленту (виртуальные ленты, а не настоящие) копирует файлы резервных копий на один конец зеркала с дедупликацией, а зеркало автоматически реплицирует в другой центр обработки данных. Это похоже на волшебство, только лучше.