Я изучал настройку, которую мы реализовали для размещенного клиента, у которого резервное копирование базы данных выполняется несколько раз в день (а последняя неделя резервного копирования всегда доступна). Скажем, для резервных копий требуется 20 ГБ, а размер диска, на котором они размещены (на самом деле, раздела), составляет 30 ГБ. На диске более 10 ГБ других «вещей», включая установку sql 2000, ОС и различные другие вещи, что означает постоянную борьбу за то, чтобы диск где-то был полностью заполнен.
Я считаю ненужным хранить неделю резервных копий на SCSI-диске, но я не эксперт в этой области и просто ищу совета от других администраторов баз данных о том, как они управляют такой схемой резервного копирования?
Стоит отметить, что в настоящее время мы используем 3 диска, зеркальную настройку рейда и запасной, который можно заменить в любой момент. Таким образом, аварийное восстановление является основной проблемой при минимизации затрат.
Любой ввод приветствуется ....
Заранее спасибо, ребята.
Не подходите к этому с точки зрения «резервного копирования», подходите к этому с точки зрения «восстановления». Сядьте и определите, что вам нужно, чтобы иметь возможность вернуть вещи, протестируйте некоторые восстановления, чтобы убедиться, что у вас есть правильный и полный список, и только затем начинайте рассматривать свою стратегию резервного копирования.
В общем, с серверным приложением резервное копирование ОС, программных файлов, конфигурации и всех других вещей я считаю важным. Восстановить необработанные данные легко, а вот конфигурацию - нет. Кроме того, у вас есть текущие уровни исправлений для возврата, ОС, а также конфигурация приложения, любые локальные учетные записи пользователей, которые вы могли создать для использования служб, и так далее.
Так что сделайте резервную копию всего и вы уверены, что ничего не пропустили, - это моя мантра.
Теперь вы храните несколько резервных копий в день в течение недели в том же хранилище, что и ОС. Это нормально, если вы случайно потеряете некоторые данные; если вы потеряете операционную систему или аппаратный сбой, вы не ошибетесь и не ошибетесь.
Один из подходов, который я использовал раньше, - это делать обычные (только) дампы данных на диск в течение дня, а полное резервное копирование всего на ленту ночью. Это сокращает требования к хранилищу для дневных дампов, что, в свою очередь, может дать более длительное окно восстановления случайно потерянных данных (за счет хранения более недели). Хранение всего на ленте означает, что я могу полностью восстановить все, даже на альтернативный сервер, если потребуется. Я мог бы пойти дальше, но сейчас мои бизнес-требования не нуждаются во мне - ваша сила.
Ваш текущий план резервного копирования, как описано, на самом деле не охватывает многих сценариев, в которых может потребоваться аварийное восстановление.
Вы должны, по крайней мере, иметь резервные копии вдали от этой машины на случай, если что-то серьезное, например, сбой источника питания, приведет к отключению всех дисков сразу, желательно на другом месте, если что-то случится со зданием, в котором расположен сервер.
Нет ничего плохого в том, чтобы хранить локальную копию резервных копий на самом сервере для облегчения доступа, например, на новом диске большего размера, как вы предлагаете, но это не должны быть ваши единственные резервные копии.
Исходя из вашего текущего положения с ограниченным пространством, я бы рекомендовал хранить только пару последних резервных копий локально на машине, а остальные хранить на более крупном диске на другой машине, желательно за пределами площадки, если это возможно (такие протоколы, как rsync, могут уменьшить полосу пропускания, необходимую для удаленного доступа). резервные копии сайта значительно). Если машина находится там, где у вас есть физический доступ к ней, вы можете вместо этого (или также) хранить автономные резервные копии, копируя их на внешний диск и храня их подальше от машины в другое время (или, что еще лучше, иметь два или более внешних диски и зациклить их - большие диски в отсеках USB в наши дни очень дешевы). В случае, если у вас есть физический доступ, лучшим вариантом может быть накопитель на магнитной ленте с большим количеством лент в цикле.
Итак, хотя у вас три диска, вы действительно используете только 1 диск, не так ли? Два привода в зеркало + третий как запасной ...
Вы можете получить немного места за счет перехода на RAID 5
При этом вы можете просто добавить еще один большой диск для хранения резервных копий, как только что было предложено в вашем вопросе.
то, что я реализовал ранее в качестве наших стандартных процедур установки / резервного копирования SQL Server (SQL 2000-2008), выглядит следующим образом
Разделение данных Разделите двоичные файлы OS / SQL, файлы данных и файлы журнала на 3 отдельных физических тома, OS / SQL на RAID 1, данные на RAID 1 (это обновление следует за комментарием Пола Рэндалла (http://www.sqlskills.com/) Логи на RAID 1. Также рекомендую 1-2 горячих резерва. Я бы порекомендовал по крайней мере какой-то уровень RAID для них всех, где это возможно, но если пространство / стоимость является проблемой, RAID 1 и размещение их всех на одном наборе дисков, у вас все равно будет тот же уровень избыточности (максимум 1 сбой диска) как RAID 5 (при условии, что 2 и 3 диска соответственно)
Настройка базы данных Внедрите 3 файла данных для каждой базы данных, MDF и LDF по умолчанию для данных и журналов, а также NDF, установите NDF в качестве файла данных по умолчанию в свойствах базы данных, оставьте MDF в покое. Я настроил все свои базы данных на модель полного восстановления, поскольку я выполняю зеркальное отображение и мне нужно иметь возможность выполнять восстановление на определенный момент времени. Я бы порекомендовал сделать это в любом случае, но при этом есть предупреждение (ниже)
РЕЗЕРВНЫЕ КОПИИ Самая важная часть настройки вашей базы данных - это правильное создание резервных копий (и связанных с ними восстановлений). Моя стандартная установка - это полное резервное копирование в 2 часа ночи, когда у нас есть узкое окно людей, не использующих базы данных (глобальная работа с персоналом в нескольких часовых поясах от Сингапура до Нью-Йорка), а затем резервное копирование журнала транзакций каждые 5 часов, начиная с 8 утра (08:00, 13:00). , 1600, 2100). Отказ от ответственности Убедитесь, что если ваши базы данных настроены на модель полного восстановления, что вы делаете Резервные копии журнала транзакций в противном случае вы можете получить чудовищные файлы журналов, и тогда вам, возможно, придется их усечь, а затем сжать, что, по словам Пола Рэндалла (Привет, Пол!), которому я бы доверял, неявно относящемуся к SQL, является aVeryBadThing (tm). Ежедневные резервные копии (включая относящиеся к ним журналы транзакций) хранятся локально на машине, затем каждую ночь собираются нашей службой резервного копирования и удаляются дежурным администратором за пределы объекта. Таким образом, если машина потеряна, мы потеряем только данные из последней полной резервной копии, а в случае, если кто-то испортит данные, только информацию, введенную между последней резервной копией T-Log и этим моментом времени (мы можем перейти к текущий журнал и воспроизведение любых других транзакций, но обычно мы этого не делаем, поскольку наши соглашения об уровне обслуживания созданы для этого) Вы, конечно, можете отправлять резервные копии журнала транзакций с компьютера или даже за пределы объекта во время создания, но это ваше решение .
Сжатие файла данных НЕ ДЕЛАЙТЕ ЭТОГО (если только вы не попадете в ситуацию, когда вы не можете этого избежать). Конечно, не планируйте это!
Индексирование и фрагментация Это должна быть ручная операция (но с использованием сценария), которая выполняется только при необходимости, вы должны проводить регулярное обслуживание, и фрагментация индекса должна быть в этом списке. В моем ежемесячном плане я проверяю размеры файлов данных, фрагментацию индекса и количество баз данных (иногда у нас есть разработчики, которые добавляют базы данных, но не сообщают нам об этом, планы обслуживания заботятся о резервных копиях, но иногда они портят макеты файлов данных. и соглашения об именах), если мы обнаруживаем какие-либо новые базы данных, они проверяются на предмет их размера, структуры файлов данных и резервных копий (никогда не помешает проверить и дважды проверить резервные копии)
Пожалуйста, не стесняйтесь выискивать дыры в вышеперечисленном или хотя бы сказать мне, что я несу чушь.