Как мы в ISPsystem резервные копии делали. Часть первая
История о том, как в ISPsystem разрабатывали решение для резервного копирования. Рассказывает руководитель разработки Александр Брюханов.
Все пользователи делятся на три группы:
те кто не делает бэкапы,
те, кто их уже делает,
и те, кто проверяет сделанные.
Кого-то мой рассказ просто повеселит, а кто-то в нем узнает себя. Это история про то, как оно было в ISPsystem 15 лет назад, как и почему менялось, к чему пришло. В первой части расскажу, как мы начали разрабатывать решение для бэкапов виртуальных серверов.
Итак, на дворе начало 2000-x. OpenVZ и KVM еще не созданы. Выходит FreeBSD Jail и на ее базе мы первыми разрабатываем решение для предоставления услуги виртуального сервера.
Если у вас появились данные, у вас появилась и проблема: как эти данные не потерять?
Поначалу обходились обычным архивированием файлов виртуального сервера, благо UnionFS это позволяет.
Правда, есть скользкий момент: при удалении файла из шаблона создается так называемый WHITEOUT, который tar не видит. Следовательно, при восстановлении из такого бэкапа, удаленные файлы, если на их месте не было создано других, восстают из пепла шаблона.
Услуга, что называется, поперла, и мы сделали инкрементальные архивы. На FreeBSD tar это умел, что называется, из коробки.
Услуга всё еще перла. Счет серверам у наших клиентов пошел не на штуки, а на стойки (для ребят, начинавших с интернетом в 56К и комнаты в 20 квадратов — это было очень неплохо). И со временем стали возникать проблемы.
Проблема первая: Процессор
Где-то в этот момент мы начали смотреть на готовые решения. Тогда кроме bacula, весьма молодого на тот момент продукта, я ничего подходящего не нашел. Мы попробовали развернуть его в одном из дата-центров, но наших ожиданий он не оправдал. Оказался довольно сложным в настройке, доставать из него файлы было не так удобно, как из обычного .tgz архива, да и производительность не впечатляла.
Понижение приоритета процессу резервного копирования тоже ни к чему хорошему не приводило: резервные копии или не успевали сделаться в течение суток или вовсе переставали создаваться.
Решение лежало на поверхности — надо вынести архивацию на отдельную машину! Благо, это делается на коленке через shell-скрипт. Сделали, и вместо обычного файл-сервера у нас появился полноценный сервер резервного копирования. Проблема с CPU была решена! Но тут же появилась другая.
Проблема вторая: Диск
Особенно при еженедельном полном резервном копировании. Ответ нашелся быстро. У нас же была предыдущая копия, в которой есть большинство файлов! Поэтому следующим шагом стало получение содержимого файлов для резервной копии не с сервера, а с предыдущей копии. Так появилась первая реализация ispbackup. И это подняло скорость в разы!
Попутно это позволило решить проблему WHITEOUT: readdir () «не видит» удаленных файлов, но их видит fts_read ()!
Используемый для сжатия gz поток в общем случае не предполагает чтения с середины, да и перепаковывать данные — занятие довольно ресурсоёмкое.
Для этого, резервные копии резались на отдельные части (часть содержала некий набор файлов целиком и имела ограничение на смещение начала файла относительно начала архива). Чтобы не перепаковывать файлы при их повторном использовании, в новом архиве могли быть использованы полностью несколько частей от предыдущего. Повторно использованные части могли содержать устаревшие данные, для избавления от них была реализована функция «сжатия» бэкапа.
Еще мы получили забавный неожиданный бонус. «Горячие» файлы начали постепенно собираться в одних частях, а «холодные» в других, что несколько оптимизировало процесс. Приятно, когда что-то хорошее происходит само по себе:)
Проблема третья: А если что-то пошло не так?
Если в какой-то момент что-то шло не так, мог создаваться битый архив, который мог месяцами оставаться незамеченным. По сути до момента, пока он тебе не понадобится… Совет, основанный на собственном горьком опыте: Если вам дороги ваши данные — проверяйте ваши бэкапы.
Эпилог
В общем, инструмент обрастал костылями. Но он работал!!! Несколько лет мы жили счастливо, а затем жесткие диски резко подешевели и размеры виртуальных машин за короткое время выросли в разы (если не на порядки).
Какое-то время мы сопротивлялись. Ввели настройку для виртуального сервера: бэкапить ли его ежедневно, еженедельно или не бэкапить вовсе, но это была уже агония. Резервное копирование уступило место надежным RAID или сетевым хранилищам с последующим их чутким мониторингом. Появился KVM и OpenVZ.
Вместо резервного копирования всех файлов мы стали писать резервное копирование пользовательских данных для ISPmanager, но это уже совсем другая история.
Кому интересно, исходный код ispbackup выложен на github.
