Стратегии резервного копирования и восстановления и программное обеспечение, используемое системными администраторами

Книга О'Рейли "Резервное копирование и восстановление". Настоятельно рекомендуется.

http://oreilly.com/catalog/9780596102463

У меня есть несколько правил для меня и моей команды. Надеюсь, некоторые из них будут вам полезны.

• Все данные (кроме журналов и кешей) должны быть скопированы. Не ждите, что система никогда не выйдет из строя. Так и будет. Иногда мы также делаем резервные копии разделов журнала и кеша, чтобы ускорить процесс восстановления системы без создания каталогов, игры с разрешениями и т. Д.
• Ведите документацию, что зарезервировано, а где зарезервировано. Когда вы работаете с любыми данными, привыкайте всегда помнить, где они сохраняются, как часто и как их восстанавливать.
• Когда вы выбираете платформу, всегда проверяйте решения для резервного копирования для нее. Особенно как быстро можно восстановить систему после сбоя. Не выбирайте платформу, пока не узнаете, как создать резервную копию, а теперь быстро восстановить. ПОПРОБУЙТЕ сделать резервную копию / восстановить его перед установкой, реклама всегда врет.
• Делайте частое резервное копирование только для часто изменяемых данных. Ежечасно создавать резервную копию всей системы - это просто глупо.
• На любом критическом сервере должен быть хотя бы один дубликат, который может автоматически заменить вышедший из строя сервер.
• Сделайте резервную копию аудита. По крайней мере, один раз в неделю. Автоматические системы резервного копирования любят отказывать, особенно за пару дней до дня X.
• Храните все возможные данные в общем хранилище. Это значительно упрощает резервное копирование. Но не доверяйте своему общему хранилищу, убедитесь, что вы можете быстро переключить все в хранилище резервных копий, предпочтительно, если система может делать это автоматически.
• Используйте моментальные снимки ZFS или аналогичную технологию. Одна полная резервная копия + инкрементальные в сочетании с полной. Если системе требуется делать полную резервную копию более одного раза - это ПЛОХАЯ система (за исключением ленты, конечно), мы живем в 21 веке.
• Когда вы выбираете ленточные решения, всегда рассчитывайте цену за ТБ. Если он равен или немного дешевле обычных HDD - забудьте про ленту. Если вам не нужно быстро восстанавливать данные, для несрочных архивов я бы предпочел ленту, даже если она дороже.
• Тренируй себя. Без обучения вы будете восстанавливать свое производство намного дольше.

и последний, основной:

• Человеческие ошибки - наиболее частая проблема потери данных. Сохраните все данные в двух копиях. Достаточно разделены, чтобы не убить обоих одной или двумя командами. Это основная причина, по которой RAID НЕ является резервной копией. Существенный аппаратный сбой только на втором или даже на третьем месте.

Что мы используем:

Что касается серверов - у нас есть все на VMWare VSphere, и мы почти довольны этим DataRecovery. Для Oracle и других баз данных мы используем их внутренние инструменты. Что касается рабочих станций - мы наконец-то перевели все на iSCSI или тонкие клиенты, так что больше никаких медленных Acronis и прочего дерьма.

У нас смешанная среда (70% Linux и 30% Windows). По (в основном) устаревшим причинам мы используем EMC Networker (с устройством смены магнитной ленты) на стороне Windows и bacula на стороне Linux. Все серверы linux покрываются bacula, а полученный каталог резервных копий на этом сервере затем включается в резервные копии EMC (размер наших ночных резервных копий составляет примерно 3 ТБ).

Основная стратегия заключается в том, что для всех машин мы покрываем только ту часть, которую невозможно восстановить из стандартных источников. Другими словами: файлы данных, базы данных, файлы конфигурации и так далее. В некоторых случаях процесс резервного копирования не имеет локального клиента и использует монтирование NFS для получения доступа к материалам, требующим резервного копирования (потому что, помимо монтирования NFS, эти целевые серверы все время меняются, и проще просто предоставить Точка монтирования NFS).

Если сервер полностью переходит в самоволку (такого никогда не было), мы покупали бы оборудование на замену, устанавливали ОС и все пакеты, восстанавливали файлы конфигурации и данные и начинали. Как уже было сказано, у нас никогда не было случая, чтобы сервер полностью перешел в режим doolally tap. Наши резервные копии в основном используются для пользователей, случайно удаляющих файлы или поврежденных. У нас были случаи, когда некоторые серверы сборки приходилось восстанавливать с нуля, потому что некоторые инженеры приводили их в такое состояние, что нормальное восстановление было невозможно, и принцип работал отлично (не считая того факта, что восстановление 30 ГБ данных просто занимает некоторое время) . Я, вероятно, должен добавить, что все наши критически важные серверы работают на RAID-массивах и резервных источниках питания, и что у нас обычно есть довольно много запасного оборудования.

Наше решение для резервного копирования, вероятно, не лучшая практика, но оно работало довольно хорошо. Среда смешанная: Windows (80%) и Linux (20%). Раньше мы использовали ленточные резервные копии для наших серверов баз данных и репозиториев системы управления версиями, но совсем недавно отказались от этой идеи (решение было принято выше моей головы!)

Мы используем StorageCraft ShadowProtect Server edition на наших серверах Windows с различными политиками в зависимости от критичности службы (например, резервное копирование Exchange выполнялось каждые полчаса). Он создает базовые образы системы с минимальным влиянием на производительность (хотя на серверах баз данных с большой нагрузкой мы действительно наблюдали ряд проблем - в основном машина зависала из-за превышения лимита ввода-вывода на диске). Он работал очень хорошо и давал нам возможность аппаратно-независимого восстановления, что означало, что нам не нужно было слишком беспокоиться о том, какого поставщика мы использовали для замены оборудования (у нас есть серверы IBM, HP, Dell и Custom build с использованием barebone-систем Tyan).

Другое дело Linux-серверы, в основном мы использовали специальные скрипты, написанные старшим системным инженером. Основной принцип заключался в том, чтобы делать резервную копию важных данных и не слишком беспокоиться об ОС.

У нас есть 40 ТБ HP EVA StorageWorks SAN для наших файловых и почтовых серверов, что обеспечивает дополнительный уровень защиты. Наши серверы резервного копирования были изготовлены на заказ с объемом хранилища 24 ТБ с использованием RAID 5. Мы используем SyncBack Pro для создания ночных резервных копий общих файловых ресурсов проекта и любых других резервных копий на уровне файлов, которые были необходимы. Попав на первичный резервный сервер, данные были отправлены на внешний сервер.

Мы также гарантируем, что у нас есть контракты на поддержку большей части нашего оборудования. 24 часа исправления для настольных ПК, 8 часов для серверов, которые у нас есть от Dell и HP, что значительно упрощает жизнь.

Принципы, которые я пытаюсь применить к резервному копированию:

1. Файлы, составляющие резервную копию, должны быть идентичны файлам, для которых создается резервная копия, для простоты восстановления. Сжатие и шифрование, если требуется, должны выполняться на уровне файловой системы.
2. Резервное копирование должно быть автоматическим и еженощным, и вы должны получить электронное письмо от процесса, когда он завершится, с указанием того, удалось ли оно выполнить или нет, и насколько заполнен носитель резервной копии.
3. Резервные копии должны храниться в географически удаленном месте для данных, которые они создают.
4. Базы данных и другие системы, для которых невозможно разумно создать резервную копию путем копирования их файлов, следует регулярно выгружать, а вместо этого делать резервные копии.

Что касается программного обеспечения, я нашел rdiff-резервное копирование - хорошее решение, позволяющее мне получить резервные копии за последние 30 дней. Я управляю простой сценарий оболочки вокруг него каждую ночь, что создает резервные копии всех моих серверов Linux на сервере резервного копирования, где резервные копии находятся в зашифрованном разделе LVM. BackupNinja работает на всех серверах и выполняет сброс баз данных и т. д. непосредственно перед запуском ночного резервного копирования.

Сделайте резервную копию на секунду. Есть три «причины» для резервного копирования ваших данных.

1) Аварийное восстановление
Это защитит вас от сценариев «в ваше здание упал метеор». Вам нужен какой-то способ быстро восстановить все ваши серверы. Классический ответ на этот вопрос - полное резервное копирование системы. Проблема в том, что по прошествии некоторого количества дней большая часть ваших данных становится практически бесполезной для аварийного восстановления (данные ОС, много статичных данных приложений и т. Д.).

2) Ошибка пользователя.
Этот тип резервного копирования охватывает «э-э, я уничтожил этот файл 2 месяца назад, и это действительно важно», или «э-э, наш администратор базы данных удалил эту таблицу, но забыл об этом ежемесячном отчете, который нам нужно запустить в последний раз» и т. Д. Как долго вы будете хранить эти резервные копии, - это бизнес-решение. Я слышал все от 1 месяца до 2 лет.

3) Архивный.
Это ДЕЙСТВИТЕЛЬНО долгосрочное резервное копирование, которое часто требуется государственными учреждениями ... «IRS требует такого класса финансовых отчетов в течение 7 или 14 лет». Хорошая новость в том, что обычно это небольшая часть ваших данных. Для этого подходят ленты или часто оптические носители.

Вооружившись этими классами данных (и хорошим аудитом вашей среды), вы можете начать классифицировать, какой тип данных вам действительно нужен.

Вот наша стратегия резервного копирования (примечание: это немного сложно). Общая стратегия: резервное копирование на диск, дублирование некоторых данных на ленту. Мы выполняем полное резервное копирование раз в месяц, резервное копирование уровня 2 - раз в неделю, а резервное копирование уровня 3 - один раз в день. Мы храним полные резервные копии 3 месяца на диске и 1 год на ленте. Мы храним резервные копии L2 в течение 4 недель, а резервные копии L3 в течение 2 недель. Это дает нам высокое «разрешение» резервного копирования за последние 2 недели и уменьшающееся разрешение по мере того, как вам нужно больше времени назад. В наших общих пользовательских ресурсах (netapp) мы не делаем резервные копии L3, вместо этого мы полагаемся на моментальные снимки. Это НАМНОГО упрощает управление восстановлением.

Однако большой выигрыш, который у нас есть, заключается в том, что у нас есть 3 «сайта». Один из них является основным сайтом, а наша среда резервного копирования (диски, медиа-серверы, ленточные роботы и т. Д.) Находится на одном из дополнительных сайтов. Это наша большая защита от проблем типа «датацентр пропал».