Подготовку нового сервера к работе следует начинать с настройки резервного копирования.
Об этом вроде бы знают все, но иногда даже опытные системные администраторы допускают непростительные ошибки.
И дело тут не только в том, что задачу по настройке нового сервера нужно решать очень быстро, но и в том, что не всегда понятно, какой метод резервного копирования следует использовать.
Конечно, невозможно создать идеальный метод, который бы подходил всем: у всего есть свои плюсы и минусы.
Но в то же время представляется вполне реальным выбрать метод, максимально соответствующий специфике конкретного проекта.
При выборе метода резервного копирования в первую очередь следует обратить внимание на следующие критерии:
Скорость (время) резервного копирования в хранилище; Скорость (время) восстановления из резервной копии; Сколько копий можно хранить при ограниченном размере хранилища (сервер резервного хранения); Объем рисков, связанных с несогласованностью резервных копий, неразработанностью метода выполнения резервных копий, полной или частичной потерей резервных копий; Оверхед: уровень нагрузки, создаваемой на сервере при выполнении копирования, снижение скорости ответа сервиса и т.д. Стоимость аренды всех использованных услуг.В этой статье мы поговорим об основных методах резервного копирования серверов под управлением Linux-систем и наиболее частых проблемах, с которыми могут столкнуться новички в этой очень важной области системного администрирования.
Схема организации хранения и восстановления из резервных копий
При выборе схемы организации способа резервирования следует обратить внимание на следующие основные моменты: Резервные копии не могут храниться в том же месте, что и данные резервной копии.Если вы храните резервную копию на том же дисковом массиве, что и ваши данные, вы потеряете ее, если основной дисковый массив будет поврежден.
Зеркальное отображение (RAID1) нельзя сравнивать с резервным копированием.
Рейд защищает лишь от аппаратной проблемы с одним из дисков (а такая проблема рано или поздно произойдет, поскольку дисковая подсистема практически всегда является узким местом сервера).
Кроме того, при использовании аппаратных рейдов существует риск выхода из строя контроллера, т.е.
нужно иметь запасную его модель.
Если вы храните резервные копии в пределах одной стойки в дата-центре или просто в пределах одного дата-центра, то в этой ситуации тоже есть определённые риски (об этом вы можете прочитать, например, Здесь .
Если хранить резервные копии в разных дата-центрах, то резко возрастают сетевые затраты и скорость восстановления из удаленной копии.
Часто причиной восстановления данных является повреждение файловой системы или дисков.
Те.
резервные копии необходимо хранить где-то на отдельном сервере хранения.
В этом случае проблема может заключаться в «ширине» канала передачи данных.
Если у вас выделенный сервер, то резервное копирование крайне желательно выполнять на отдельном сетевом интерфейсе, а не на том же, который обменивается данными с клиентами.
В противном случае запросы вашего клиента могут «не вписаться» в ограниченный канал коммуникации.
Или из-за загруженности клиентов резервные копии не будут сделаны вовремя.
Далее необходимо продумать схему восстановления данных и время с точки зрения хранения резервных копий.
Вас может вполне устроить резервное копирование за 6 часов ночью на хранилище с ограниченной скоростью доступа, но восстановление за 6 часов вас вряд ли устроит. Это значит, что доступ к резервным копиям должен быть удобным и данные должны копироваться достаточно быстро.
Так, например, восстановление 1ТБ данных с пропускной способностью 1Гбит/с займет почти 3 часа, и это если вы не ограничены производительностью дисковой подсистемы в хранилище и сервере.
И не забудьте прибавить к этому время обнаружения проблемы, время принятия решения об откате, время проверки целостности восстановленных данных и количество последующего недовольства клиентов.
коллеги.
Инкрементное резервное копирование
В постепенный При резервном копировании копируются только файлы, которые изменились с момента предыдущего резервного копирования.Инкрементное копирование чаще всего выполняется с помощью утилиты rsync. С его помощью вы сможете сэкономить место для хранения, если количество изменений в день не очень велико.Последующие инкрементальные резервные копии добавляют только файлы, которые изменились со времени предыдущего.
В среднем инкрементное резервное копирование занимает меньше времени, поскольку копируется меньше файлов.
Однако процесс восстановления данных занимает больше времени, поскольку необходимо восстановить данные из последней полной резервной копии, а также данные всех последующих инкрементных резервных копий.
При этом, в отличие от дифференциального копирования, измененные или новые файлы не заменяют старые, а добавляются на носитель самостоятельно.
Если измененные файлы большие, они будут скопированы полностью без замены предыдущих версий.
Процесс резервного копирования rsync можно разделить на следующие этапы:
Список файлов формируется на резервном сервере и в хранилище; для каждого файла считываются метаданные (разрешения, время модификации и т. д.) или контрольная сумма (при использовании ключа –checksum).Если метаданные файлов различаются, то файл разбивается на блоки и для каждого блока рассчитывается контрольная сумма.
Блоки, отличающиеся друг от друга, загружаются в хранилище.
Если в файле происходит изменение во время подсчета контрольной суммы или передачи файла, его резервное копирование повторяется с начала.
По умолчанию rsync передает данные через SSH, а это означает, что каждый блок данных дополнительно шифруется.
Rsync также можно запускать как демон и передавать данные без шифрования, используя его протокол.
Более подробную информацию о том, как работает rsync, можно найти по адресу
Официальный веб-сайт .Для каждого файла rsync выполняет очень большое количество операций.
Если на сервере много файлов или сильно загружен процессор, то скорость резервного копирования существенно снизится.
По опыту можем сказать, что проблемы на SATA-дисках (RAID1) начинаются примерно после 200 ГБ данных на сервере.
На самом деле все, конечно, зависит от количества инодов.
И в каждом случае это значение может смещаться в ту или иную сторону.
После определенного момента время выполнения резервного копирования будет очень долгим или просто не будет выполнено за день.
Чтобы не сравнивать все файлы, есть lsyncd. Этот демон собирает информацию о файлах, которые изменились, т.е.
у нас уже заранее будет готов их список для rsync. Однако следует учитывать, что это создает дополнительную нагрузку на дисковую подсистему.
Дифференциальное резервное копирование
В дифференциал При резервном копировании каждый файл, который изменился с момента последнего полного резервного копирования, копируется каждый раз.Дифференциальное резервное копирование осуществляется, например, с помощью такой утилиты, как rdiff-backup. При работе с этой утилитой возникают те же проблемы, что и при инкрементном резервном копировании.Дифференциальное копирование ускоряет процесс восстановления.
Все, что вам нужно, — это последняя полная и последняя дифференциальная резервная копия.
Дифференциальное резервное копирование становится все более популярным, поскольку все копии файлов создаются в определенные моменты времени, что, например, очень важно при заражении вирусами.
В целом, если при поиске различий в данных производится полный перебор файлов, то проблемы такого резервного копирования аналогичны проблемам с rsync. Хотим отдельно отметить, что если в вашей схеме резервного копирования каждый файл копируется отдельно, то вам следует удалить/исключить файлы, которые вам не нужны.
Например, это могут быть кэши CMS. Такие кэши обычно содержат множество мелких файлов, потеря которых не повлияет на корректную работу сервера.
Полное резервное копирование
Полная резервная копия обычно влияет на всю вашу систему и все ваши файлы.Большинство публикаций по соответствующей теме рекомендуют выполнять полное резервное копирование один или два раза в неделю, а в остальное время использовать инкрементное и дифференциальное резервное копирование.Еженедельное, ежемесячное и ежеквартальное резервное копирование предполагает создание полной копии всех данных.
Обычно оно выполняется по пятницам или в выходные дни, когда копирование большого объема данных не влияет на работу организации.
Последующие резервные копии, выполняемые с понедельника по четверг до следующего полного резервного копирования, могут быть дифференциальными или инкрементальными, главным образом для экономии времени и места на носителе.
Полное резервное копирование следует выполнять как минимум еженедельно.
Для такого совета есть причина.
В большинстве случаев полного резервного копирования раз в неделю достаточно.
Имеет смысл запустить его еще раз, если у вас нет возможности обновить полную резервную копию на стороне хранилища и убедиться в корректности резервной копии (это может понадобиться, например, в тех случаях, когда по тем или иным причинам , вы не доверяете имеющимся у вас сценариям или программному обеспечению для резервного копирования.
Фактически полную резервную копию можно разделить на две части:
- Полное резервное копирование на уровне файловой системы;
- Полное резервное копирование на уровне устройства.
root@komarov:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/komarov_system-root 3.4G 808M 2.4G 25% / /dev/mapper/komarov_system-home 931G 439G 493G 48% /home udev 383M 4.0K 383M 1% /dev tmpfs 107M 104K 107M 1% /run tmpfs 531M 0 531M 0% /tmp none 5.0M 0 5.0M 0% /run/lock none 531M 0 531M 0% /run/shm /dev/xvda1 138M 22M 109M 17% /bootМы зарезервируем только /дом.
Все остальное можно быстро восстановить вручную.
Вы также можете развернуть сервер с системой управления конфигурациями и подключить к нему наш /home.
Полное резервное копирование на уровне файловой системы
Типичный представитель: дамп.Утилита создает «дамп» файловой системы.
Вы можете создать не только полную, но и инкрементальную резервную копию.
dump работает с таблицей индексных дескрипторов и «понимает» файловую структуру (поэтому разреженные файлы сжимаются).
Создавать дамп работающей файловой системы «глупо и опасно», поскольку файловая система может измениться во время создания дампа.
Его необходимо создать из снимка (чуть позже мы обсудим особенности работы со снимками более подробно), смонтированной или замороженной файловой системы.
Эта схема также зависит от количества файлов, и время ее выполнения будет увеличиваться вместе с объемом данных на диске.
При этом dump имеет более высокую скорость работы, чем rsync. Если вам нужно восстановить не всю резервную копию, а, например, только пару случайно поврежденных файлов), восстановление таких файлов утилитой восстановления может занять слишком много времени.
Полное резервное копирование на уровне устройства
- mdraid и DRBD
Фактически RAID1 настроен с диском/рейдом на сервере и сетевым диском, и время от времени (в зависимости от частоты резервного копирования) дополнительный диск синхронизируется с основным диском/рейдом на сервере.
Самым большим преимуществом является скорость.
Продолжительность синхронизации зависит только от количества изменений, внесенных за последние сутки.
Эта система резервного копирования используется довольно часто, но мало кто осознает, что резервные копии, полученные с ее помощью, могут оказаться неэффективными, и вот почему.
По завершении синхронизации дисков диск, содержащий резервную копию, отключается.
Если, например, у нас работает СУБД, которая порциями записывает данные на локальный диск, сохраняя промежуточные данные в кэше, нет никакой гарантии, что они вообще окажутся на резервном диске.
В лучшем случае мы потеряем часть изменяемых данных.
Поэтому такие резервные копии вряд ли можно считать надежными.
- LVM+дд
Снимки — отличный инструмент для создания согласованных резервных копий.
Перед созданием снапшота необходимо сбросить кеш ФС и вашего ПО на дисковую подсистему.
$ sudo mysql -e 'FLUSH TABLES WITH READ LOCK;' $ sudo mysql -e 'FLUSH LOGS;' $ sudo sync $ sudo lvcreate -s -p r -l100%free -n %s_backup /dev/vg/%s $ sudo mysql -e 'UNLOCK TABLES;'* Коллеги рассказывают истории о том, как у кого-то «блокировка чтения» иногда приводила к взаимоблокировкам, но на моей памяти такого еще не было.
Далее вы можете скопировать снимок в хранилище.
Главное следить, чтобы снимок не самоуничтожился при копировании и не забывать, что при создании снимка скорость записи существенно упадет. Резервные копии СУБД можно создавать отдельно (например, с помощью бинарных журналов), тем самым исключая простои при сбросе кэша.
А дампы в хранилище можно создавать, запустив там экземпляр СУБД.
Резервное копирование различных СУБД — тема для отдельных публикаций.
Копировать снапшот можно с помощью возобновления (например, rsync с патчем для копирования блочных устройств bugzilla.redhat.com/show_bug.cgiЭid=494313 ), можно блоками и без шифрования (netcat, ftp).
Вы можете передавать блоки в сжатом виде и монтировать их в хранилище с помощью AVFS, а раздел с резервными копиями монтировать на сервере через SMB. Сжатие устраняет проблемы скорости передачи, засорения каналов и места для хранения.
Но, если вы не используете AVFS в своем хранилище, то на восстановление только части данных у вас уйдет много времени.
Если вы используете AVFS, вы столкнетесь с его «сыростью».
Альтернативой блочному сжатию является squshfs: можно смонтировать, например, раздел Samba на сервер и запустить mksquashfs, но эта утилита работает и с файлами, т.е.
зависит от их количества.
Кроме того, при создании сквошфов тратится много оперативной памяти, что легко может привести к вызову oom-killer.
Безопасность
Необходимо обезопасить себя от ситуации, когда хранилище или ваш сервер будут взломаны.Если сервер взломан, то лучше, чтобы у пользователя, записывающего туда данные, не было прав на удаление/изменение файлов в хранилище.
Если хранилище взломано, то также желательно максимально ограничить права резервного пользователя на сервере.
Если резервный канал можно подслушать, то необходимо шифрование.
Заключение
Каждая система резервного копирования имеет свои плюсы и минусы.В этой статье мы постарались осветить некоторые нюансы при выборе системы резервного копирования.
Надеемся, они помогут нашим читателям.
В результате, выбирая систему резервного копирования для вашего проекта, вам необходимо провести тестирование выбранного типа резервного копирования и обратить внимание на:
- время резервного копирования на текущем этапе проекта;
- время резервного копирования в случае, если данных в разы больше;
- нагрузка на канал;
- нагрузка на дисковую подсистему на сервере и в хранилище;
- время для восстановления всех данных;
- время восстановления пары файлов;
- необходимость обеспечения согласованности данных, особенно в базах данных;
- потребление памяти и наличие вызовов oom-killer;
Читатели, которые не могут оставлять здесь комментарии, приглашаются посетить нас по адресу: блог .
Теги: #selectel #Резервное копирование #резервные копии
-
Ваш Отзыв Бесценен Для Нас
19 Oct, 24 -
Китайский Краудфандинг, Или Скрытый Дракон
19 Oct, 24 -
Оценка Требований В Scrum
19 Oct, 24 -
Торрентс.ру Активно Борется С Читерами
19 Oct, 24 -
Анимированные Линии В Ios
19 Oct, 24
