Когда я читал сообщение в блоге Джеффа Наша стратегия резервного копирования Подробно описывая, как они настраивают среду резервного копирования, многие люди отметили, что это не очень хороший подход.
Моя компания в настоящее время еще не настроила решение для резервного копирования, и я думаю, что это то, что нам действительно нужно сделать в ближайшее время.
Но существует так много разных подходов или решений, что я не знаю, какой из них делать.
У меня есть несколько возможных идей, что делать:
Создайте небольшую виртуальную машину на нашем текущем веб-сервере, которая выполняет резервное копирование всех данных на NAS.
Установите другую машину внутри компании, у которой много места для хранения и которая хранит все данные на жестких дисках.
Установите еще одну небольшую машину в доме, которая выполняет резервное копирование данных на NAS.
Воспользуйтесь услугами онлайн-резервного копирования (какую из них вы можете порекомендовать?)
Некоторая информация о нашей технической среде:
У нас есть один большой сервер с несколькими виртуальными машинами (сервер базы данных, веб-сервер, сервер VPN для нашего офиса и т. Д.). Нам нужно сделать резервную копию всех наших данных Subversion и, конечно же, электронной почты и ежедневных дампов баз данных.
Буду признателен за любой совет.
Я не думаю, что есть такая вещь, как единственная оптимальная стратегия резервного копирования. Во многом это зависит от того, что вы создаете резервную копию и сколько из них есть. Во-вторых, это должно определяться вашими требованиями к восстановлению, а именно тем, насколько быстро вы можете вернуть вещи и сколько вы можете позволить себе потерять в случае сбоя. Наконец, вам нужно помнить, что вам необходимо охватить как минимум 2 уровня восстановления: восстановление отдельных элементов данных и полное восстановление сервера.
Я всегда предпочитаю ленту NAS, но по какой-то причине у ленты есть плохая репутация в определенных кругах. Однако одним из основных преимуществ является то, что он физически отделен от любой ОС (или другой логической) среды, поэтому вы значительно уменьшаете такие проблемы, как создание резервной копии сервера резервного копирования и реализация чистой и простой стратегии вне офиса.
Мой стандартный совет с резервными копиями - делайте их как можно более простыми и примитивными, чтобы ваши восстановления также были простыми и чтобы было меньше уровней сексуальности, которые потенциально могут пойти не так. Резервное копирование должно быть предсказуемым и утомительным.
Онлайн-резервное копирование - это то, что людям может показаться заманчивым, но вы всегда должны помнить, что через некоторое время вам может потребоваться полное восстановление сервера. Если у вас нет пропускной способности для вашего провайдера, сопоставимой с вашей локальной пропускной способностью, я бы держался подальше.
Вам необходимо иметь резервные копии как внутри компании, так и за ее пределами. Те, что находятся в доме, предназначены для быстрого восстановления, а те, которые находятся за пределами объекта, - на случай, если ваш «дом» взорвется.
Я бы рекомендовал максимально использовать RAID-6 с контроллером с резервным аккумулятором, установленным на любой резервной машине.
Я не знаю, какие службы резервного копирования вам известны, но любая из них, предлагающая неограниченное пространство, - это очень плохая идея.
Начать нужно с бизнес-требований. Стратегии резервного копирования начинаются с обдумывания плана восстановления. Выясните, какие резервные копии необходимо выполнять ежедневно (возможно, даже ежечасно), чтобы возобновить работу этой конкретной бизнес-функции в любой требуемый период времени. Резервные копии могут не потребоваться для выполнения требуемых функций. Например, если мне нужен файловый сервер, чтобы иметь возможность восстанавливать любой файл, удаленный в течение 30 минут, я бы настроил службу теневого копирования тома в Windows, чтобы делать снимки каждые 15 минут.
Когда у вас есть бизнес-требования, вы можете определить, что технически требуется для их реализации. Вы заметите, что в комментариях аргументы касались стоимости / производительности, надежности и т. Д. Все вопросы бизнеса.
Позвольте мне начать с того, что любая система резервного копирования лучше, чем никакая, но если вы собираетесь выполнять резервное копирование только на другую машину или устройство хранения в том же месте, это ненамного лучше, чем ничего. Вам нужен способ хранить резервные копии за пределами сайта. Я всегда предпочитаю использовать кассеты. Некоторые предложат удаленное хранилище через Интернет, но это определенно не является глобально жизнеспособным решением. Это также добавляет риски, связанные с хранением ваших данных в неизвестном месте и доступными для неизвестного количества людей. Независимо от того, какой метод вы используете, резервная копия хороша настолько, насколько хороша ваша способность выполнить восстановление.
В настоящее время я работаю в компании, которой пришлось восстанавливать с нуля после того, как пожар полностью уничтожил их последние помещения, включая все в нем. Благодаря адекватным удаленным резервным копиям они могли это сделать. Как бы поступила ваша компания в таких же обстоятельствах? Согласно некоторым статистическим данным, которые я видел, большинство предприятий обанкротятся в течение первого года после такой катастрофы, и одной из основных причин является потеря критически важных данных, что обычно приводит к потере бизнеса.
Первый шаг, когда вы думаете о резервном копировании, - это цена ваших данных и, отдельно, время простоя. Как только эти шаги будут предприняты, все остальное более или менее встанет на свои места.
mh говорит мудрые вещи. Как и он, я являюсь «традиционалистом» и считаю, что должным образом управляемое и обслуживаемое резервное копирование на магнитной ленте предлагает множество преимуществ (легкость переноса за пределы площадки и в автономный режим, низкие дополнительные затраты на добавление емкости, «серьезные» ленточные технологии (такие как LTO и DLT). ) иметь носитель, способный к долгосрочному архивированию) только на дисковое резервное копирование. С диска на диск на ленту - отличный способ сократить окна резервного копирования и обеспечить удобное восстановление, и стоимость, как правило, увеличивается по сравнению с лентой, поскольку коробка заполнена умеренно быстрыми дисками (например, некоторыми большими дисками SATA в конфигурации RAID ) не слишком дорого.
Ни один из предложенных вами методов не упоминает перевод резервных копий в автономный режим. Резервное копирование выполняется как вне офиса, так и вне его. Хранение ваших резервных копий в сети означает, что злоумышленник может уничтожить ваши резервные копии сразу после того, как они уничтожили ваши производственные данные. Ужасно сложно удаленно атаковать физический носитель, хранящийся за пределами предприятия, в физически безопасном месте.
Если вы решите делать резервные копии на диск, я настоятельно рекомендую регулярно делать резервные копии в автономном режиме и за пределами сайта.
Что бы вы ни делали, тестовое восстановление в порядке. Мы не делаем резервные копии, чтобы «иметь резервные копии». Делаем бэкап для восстановления. Вам необходимо регулярно тестировать резервные копии, выполняя восстановление. Вам нужно знать, как выполнять восстановление, и вам нужно выполнять их периодически. Ваше отношение, re: restore, должно быть таким: «Был там, сделал это». Когда случается настоящая катастрофа, последнее, о чем вы хотите беспокоиться, - это научиться восстанавливать свои системы из мертвых.
Как я сказал в своем комментарии к ответу mh, онлайн-резервное копирование настолько хорошо, насколько хорош механизм восстановления (поскольку, опять же, мы делаем резервную копию для восстановления). Если для восстановления ваших данных от онлайн-провайдера резервного копирования потребуется 36 часов подряд, а ваш бизнес не может справиться с 36 часами простоя, то это, вероятно, плохая сделка. При этом, если вы можете структурировать онлайн-резервные копии, чтобы улавливать медленно изменяющиеся «архивные» данные, которые не критичны для повседневного бизнеса, вы можете использовать их как стратегию хранения вне площадки, тем самым уменьшая количество критически важных для бизнеса данные, которые должны быть на физическом носителе, который вы берете за пределы офиса.
Уже есть несколько хороших вопросов по этому поводу в Server Fault. Я бы пошел и прочитал их. Вот несколько, которые мне сразу приходят в голову.
Резервное копирование - это самая важная вещь, которую делают администраторы. ....
Позвольте мне повторить.
Резервное копирование - это самая важная вещь, которую делают администраторы.
Хорошая стратегия резервного копирования позволяет восстановить различные виды потери данных, в том числе ...
1- аппаратный сбой.
2- ошибки данных / приложений и повреждение данных.
3- непреднамеренное или вредоносное удаление файла / папки / данных.
4- проблемы с площадкой или инфраструктурой (например, пожар в серверной).
5- региональная катастрофа (например, ураган Катрина)
Хорошая стратегия уравновешивает ценность данных и стоимость простоя с вероятностью сбоя, доступными средствами и стоимостью различных типов систем резервного копирования.
Как минимум, у вас должно быть ежедневное резервное копирование на ленту всех данных и какая-то схема хранения этих резервных копий за пределами площадки. Полное резервное копирование на выходных и инкрементное резервное копирование каждую ночь можно. Мне нравится 4-недельная ротация лент. Резервные копии следует регулярно тестировать (посредством восстановления и восстановления тестового сервера).
Кстати - ИМХО нашему уважаемому хосту необходимо улучшить внешний компонент стратегии резервного копирования Stack Overflow.