как сделать бэкап линукс
Программы резервного копирования Linux
Системные администраторы шутят, что люди делятся на два типа: те кто не делает резервные копии и те, кто уже делает резервные копии. В работе любого пользователя или системного администратора рано или поздно возникнет момент, когда что-то сломается и важные данные будут утеряны. Если до этого человек резервных копий не делал, то теперь научится и начнёт делать.
Если для домашних пользователей это, в принципе, не очень актуально, то для производственных серверов потеря данных может привести к большим финансовым потерям, поэтому важно всегда иметь хотя бы копию файлов и базы данных просто на всякий случай. В этой статье мы рассмотрим основные инструменты, которые можно использовать для резервного копирования различных элементов системы.
Программы для резервного копирования в Linux
1. Rsync
Утилита rsync не предназначена специально для резервного копирования, но её можно для этого использовать. Эта программа позволяет копировать файлы из одного компьютера на другой по протоколу SSH или своему собственному протоколу Rsync, но для последнего понадобиться чтобы на целевом компьютере был установлен сервер Rsync. Одно из преимуществ программы в том, что она позволяет не передавать через сеть всё содержимое файлов, а только те данные, которые изменились с последнего копирования. Это удобно для того чтобы не перегружать сеть лишними операциями. Никаких автоматизированных решений здесь нет, вам самим придётся настраивать что и куда копировать. Подробнее про Rsync читайте в этой статье.
2. AutoMysqlBackup
Если вам надо делать резервную копию базы данных MySQL, то для этого нельзя просто скопировать все файлы базы данных. Лучше скопировать нужные базы с помощью специального инструмента. К таким инструментам относится скрипт AutoMySQLBackup. С помощью него вы можете настроить регулярное резервное копирование вашей базы данных на другой сервер или в облако. Поддерживается ротация и удаление устаревших резервных копий.
3. Duplicity
4. Rdiff-backup
Ещё одна небольшая утилита для резервного копирования, похожая на rsync. Она написана на Python и позволяет делать резервные копии только изменённых файлов. Кроме того, можно хранить резервную копию на другом сервере. На удалённый сервер можно записывать данные по протоколу rsync или ssh.
5. Bacula
Это уже не просто скрипт, а полноценная система резервного копирования, которую надо размещать на нескольких серверах. Она состоит из нескольких компонентов, каждый из которых имеет своё предназначение. Программа имеет открытый исходный код и предназначена, в первую очередь, для предприятий. Кроме полных резервных копий, так же как и в Rsync поддерживаются инкрементные, когда копируются только изменённые данные.
6. Backupninja
7. Kbackup
Это небольшая графическая утилита для резервного копирования файлов разработанная для KDE. Позволяет выполнять как полные резервные копии так и архивировать только изменённые файлы. Копии хранятся только на том же компьютере, что и установлена программа, а автоматическое резервное копирование не поддерживается.
8. BackupPC
Это кроссплатформенная программа для резервного копирования, разработанная для больших предприятий. Для управлением резервным копированием используется веб-интерфейс. Можно делать как полные резервные копии, так и только для изменённых файлов. Можно запланировать автоматическое обновления или настроить уведомления о необходимости делать резервные копии.
9. Amanda
Amanda расшифровывается как Advanced Maryland Automatic Network Disk Archiver. Это тоже кроссплатфноменная программа для резервного копирования, созданная, в первую очередь, для предприятий. Она может располагаться на нескольких компьютерах, благодаря клиент-серверной архитектуре и сохранять резервные копии на другой сервер. Для создания резервных копий используются системные утилиты, в Linux это tar.
10. Back In Time
Это простая графическая утилита для настройки автоматического резервного копирования. Поддерживается как копирование на локальный компьютер, так и хранение копий удалённо. Вы можете выбрать папки, которые надо копировать и расположение, куда копировать.
11. Box Backup Tool
Ещё один инструмент корпоративного уровня. Его можно установить на несколько машин и выполнять резервное копирование между ними. Программой можно управлять только с помощью командной строки. Поддерживаются инкрементальные копии, а также шифрование данных.
12. Luckybackup
Это ещё одна оболочка над утилитой rsync, только на этот раз с графическим интерфейсом. Она позволяет планировать автоматическое резервное копирование, выполнять полные копии или только синхронизировать изменения с сервером. Интерфейс утилиты интуитивно понятный и достаточно удобен в использовании.
13. Timeshift
Раньше мы рассматривали программы, предназначенные для резервного копирования отдельных файлов и каталогов, однако существуют программы предназначенные для полного копирования всех файлов операционной системы. К ним относится Timeshift. Программа имеет как графический так и консольный интерфейс и позволяет создавать резервные копии системы с помощью rsync или btrfs. Подробнее об её возможностях читайте тут.
14. Clonezilla
В отличие от Timeshift программа Clonezilla поставляется на отдельном образе и запускается из BIOS. Она позволяет создать резервную копию как Linux так и Windows потому что копирует весь диск побайтово и потом позволяет всё это восстановить. Подробнее о том как пользоваться Clonezilla читайте в отдельной статье.
15. Systemback
Утилита Systemback чем-то похожа на Timeshift. Она тоже позволяет создавать точки восстановления операционной системы и потом с помощью них восстанавливать работу вашего дистрибутива. Кроме того, с помощью утилиты можно скопировать систему на другой диск или создать LiveCD образ для будущего восстановления.
Выводы
Всегда помните, что резервное копирование очень важно, оно помогает предотвратить потерю данных. Существует огромное количество программ резервного копирования Linux, которые помогут регулярно копировать ваши данные.
Вы можете выбрать один из выше рассмотренных инструментов, просто выберите что для вас подходит лучше. Если вы используете другую программу, не описанную здесь, напишите в комментариях!
Резервное копирование Ubuntu
Резервное копирование системы очень важно, поскольку если у вас есть резервная копия всех файлов, настроек или даже системы полностью, то вы можете ее восстановить в случае возникновения проблем. Несмотря на стабильность Linux, эта система может ломаться, например, после обновления или когда вы экспериментировали и сделали что-то не так.
Резервное копирование Ununtu
Рассмотрим самые распространенные способы копирования среди администраторов и обычных пользователей.
Способ 1. Список пакетов
Самый простой способ резервного копирования Ubuntu, кстати, именно эту возможность использует MintBackup в LinuxMint, это получение списка всех установленных пакетов. Да, тут вы не сохраните всю конфигурацию, зато сможете очень быстро восстановить все установленные программы.
Если учесть, что большинство конфигурационных файлов находятся в домашней папке пользователя, а она не стирается при переустановке, то остальные файлы не такая уже большая проблема. А такая резервная копия будет занимать всего несколько килобайт. Для выполнения резервной копии наберите такую команду:
Далее, скопируйте полученный файл в надежное место. Когда система сломается, переустановите ее с установочного носителя, а затем просто выполните команды:
Файл со списком пакетов нужно поместить в текущую папку. Таким образом, вы очень быстро вернете все ранее установленные программы с минимальными затратами времени и в то же время получите чистую систему.
Способ 2. Создание архива
Резервное копирование таким способом более надежно, поскольку вы не просто создаете список установленных программ, а делаете архив из всей файловой системе. Фактически, вы можете потом развернуть этот архив на любой машине и получить полноценную операционную систему после настройки драйверов.
Таким способом часто создаются резервные копии систем на серверах и для него достаточно просто использовать утилиту tar и не нужны сторонние программы. Для создания архива используйте такую команду:
Если система повреждена, вам нужно загрузиться с LiveCD/USB, и примонтировать корневой каталог в /mnt/. Затем подключите носитель с резервной копией и выполните команду для распаковки:
Команда быстро распакует все, что было сохранено и вам останется только перезагрузить компьютер, чтобы вернуться к своей основной системе. Здесь не восстанавливается только загрузчик, восстановить Grub нужно отдельно если он был поврежден.
Способ 3. Резервное копирование в rsync
Этот способ очень похож на второй, но здесь архив не создается, а данные просто переносятся в другую папку. Это может более полезно при простом копировании операционной системы в другое место. Команда выглядит вот так:
После завершения копирования вам останется отредактировать /etc/fstab и заменить в нем адрес корневого раздела на новый. А также создать новый конфигурационный файл для загрузчика, автоматически или вручную.
Способ 4. Создание образа раздела
Команда dd linux позволяет создать полную копию раздела или даже всего диска. Это самый надежный, но в то же время потребляющий большое количество памяти способ выполнить резервное копирование системы Ubuntu. Утилита просто переносит весь диск по одному байту в образ. Команда выглядит вот так:
sudo dd if=/dev/sda4 of=
Правда, процесс может занять достаточно много времени, в зависимости от скорости работы вашего диска.
Способ 5. Создание Squashfs образа
Преимущество Squashfs в том, что это полноценная файловая система в одном файле, которую можно очень быстро примонтировать и быстро извлечь нужные файлы. Кроме того, файловую систему можно открыть привычными менеджерами архивов. Для создания образа со всей системы используйте:
Теперь, чтобы примонтировать созданный образ будет достаточно набрать такую команду:
Выводы
Резервное копирование Ubuntu 16.04 очень важно для поддержания вашей операционной системы в нормальном состоянии. В случае любой неожиданной ситуации вы сможете все восстановить. Если вас интересуют графические программы для бэкапа, вы можете попробовать remastersys или timeshift. Надеюсь, эта информация была полезной для вас.
Оцените статью:
Об авторе
Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.
28 комментариев
теперь ждёмс статью со способами автоматического бэкапа без скриптописания и статью о том как работать со снапшотами btrfs
Спасибо, за статью.
Как раз исследовал этот вопрос и тут как раз Вы.
спасибо. Получился в дом. папке «backup.txt», который пуст. Что-то не так с моей системой, ничего проинсталлировать не могу, apt-get update тоже не работает. Если не найду причину, придеться переустанавливать систему. Эх..
Похоже, xneur првратил два минуса подряд в тире. Минус-пробел-минус, пробел стереть. Или xneur отключить/настроить.
Спасибо, точно так оно и было (с «Минус-пробел-минус»). Backup был установлен. Как, имея его теперь, лучше переинсталлировать глючную систему?
>(Zorin на остнове Ubuntu 14.04) Есть ли другое решение?
Понаставляют всяких болгеносов, а потом мучаются..
А есть ли утилиты, которые позволяют делать backup системы, но с расчетом, чтобы каждый раз не был Full, а также поддерживал бы дифференциальный?Понятно, что всякие дополнительные мощные средства как Symantec, Acronis, Veeam и др. умеют это делать, но именно чтобы были утилиты небольшие по размеру и желательно из репов и бесплатные?
можно попробовать Aptik
Возможности
Поддержание/восстановление пакетов приложений и PPA
Поддержание/восстановление установленных пакетов
Поддержание/восстановление иконок из директории /usr/share/icons и тем из директории /usr/share/themes
Поддержание/восстановление настроек приложений. Оно сохраняет zip-архивы разделов конфигураций приложений из домашней директории в местоположение резервных копий.
Поддержание/восстановление пользователей и групп. Создает резервные копии пользователей и групп и восстанавливает их на новой системе
Поддержание/восстановление записей. Создает резервные копии записей в директориях /etc/fstab и /etc/crypttab и восстанавливает их на новой системе
Поддержание/восстановление данных в директории Home. Создает резервные копию данных пользовательской директории Home и восстанавливает ее на новой системе
Запланированные задачи. Создает резервные копии записей файлов заданий crontab для всех пользователей и восстанавливает их на новой системе
Зашифрованные резервные копии. Резервные копии, содержащие личную информацию, шифруются с использованием AES-128.
Отдельные или периодические операции. Можно создавать копии как одного, так и нескольких объектов
Поддержка всех видов Ubuntu и производных (Linux Mint, Elementary OS и т.д.).
Доступна для Ubuntu 17.04 Zesty/16.10 Yakkety/16.04 Xenial/14.04 Trusty/12.04 Precise/Linux Mint 18/17/13/и других производных Ubuntu.
Для установки следующие команды:
sudo add-apt-repository ppa:teejee2008/ppa
sudo apt-get update
sudo apt-get install aptik
Я использую «Luckybackup», графическая среда для rsync!
установка: sudo add-apt-repository ppa:luckybackup-maintainers/ppa
sudo apt-get update
sudo apt-get install luckybackup
НУ что сказать, работает! Правда были проблемы с cron, в приложении есть возможность создания но не запуска)
Решил установкой «Gnome Shedule»
sudo apt-get install gnome-schedule
Sheduler подтянул задания на выполнение и всё!
А есть вариант этой проги, но не GUI? У нас X-сервер нигде не установлен.
А почему ни слова не сказано про fsarchiver? Утилита намного лучше, удобней и понятней в эксплуатации, чем клонезилла, я только fsarchiver-ом и пользуюсь, нареканий лет за 6 работы на моей машине никаких!
Имеет ли смысл делать резервную копию в Bacula Backup System в Webmin? Если да, то как? Нигде не нашел внятную инструкцию.
У Bacula есть свой же Web- интерфейс, через него обычно все и работает.
Есть же штатная Backups еще.
И Systemback. правда восстанавливать систему пока еще ни разу не пришлось, в отличие от Windows)
Здравствуйте! Спасибо за статью, для чайника познавательно! Скажите, а есть программы для создания бекапа по расписанию? Типа acronis
«РЕЗЕРВНОЕ КОПИРОВАНИЕ UNUNTU»
Мелочь, но исправьте.
автор, а можно поподробнее про СОЗДАНИЕ SQUASHFS ОБРАЗА пожалуйста, что бы восстановить какая полная команда будет? и откуда, не понятно ничего. опиши, если не трудно
Способ 2. Создание архива. Корневая папка будет LiveCD, а не нашей системы, которой надо копию сделать. Надо сначала смонтировать корневой раздел нашей системы в какую либо папку внутри mnt (например, mount/root), а уже потом этот раздел копировать в файл на флешке или внешнем жестком диске. Но тогда встает другая проблема. В архивный файл попадет структура mnt/root и при разархивировании будет не корневой раздел а mount/root/корневой_раздел
Результат:
tar: Удаляется начальный `/’ из имен объектов
tar: Удаляются начальные `/’ из целей жестких ссылок
tar: /var/snap/canonical-livepatch/98/livepatchd.sock: сокет проигнорирован
tar: /var/snap/canonical-livepatch/98/livepatchd-priv.sock: сокет проигнорирован
tar: /run/wpa_supplicant/wlo1: сокет проигнорирован
tar: /run/irqbalance/irqbalance484.sock: сокет проигнорирован
tar: /run/uuidd/request: сокет проигнорирован
tar: /run/snapd-snap.socket: сокет проигнорирован
tar: /run/snapd.socket: сокет проигнорирован
tar: /run/dbus/system_bus_socket: сокет проигнорирован
tar: /run/cups/cups.sock: сокет проигнорирован
tar: /run/avahi-daemon/socket: сокет проигнорирован
tar: /run/acpid.socket: сокет проигнорирован
tar: /run/user/1000/doc: Функция stat завершилась с ошибкой: Отказано в доступе
tar: /run/user/1000/gvfs: Функция stat завершилась с ошибкой: Отказано в доступе
tar: /run/user/1000/keyring/ssh: сокет проигнорирован
tar: /run/user/1000/keyring/pkcs11: сокет проигнорирован
tar: /run/user/1000/keyring/control: сокет проигнорирован
tar: /run/user/1000/snapd-session-agent.socket: сокет проигнорирован
tar: /run/user/1000/pulse/native: сокет проигнорирован
tar: /run/user/1000/pk-debconf-socket: сокет проигнорирован
tar: /run/user/1000/gnupg/S.gpg-agent: сокет проигнорирован
tar: /run/user/1000/gnupg/S.gpg-agent.ssh: сокет проигнорирован
tar: /run/user/1000/gnupg/S.gpg-agent.extra: сокет проигнорирован
tar: /run/user/1000/gnupg/S.gpg-agent.browser: сокет проигнорирован
tar: /run/user/1000/gnupg/S.dirmngr: сокет проигнорирован
tar: /run/user/1000/bus: сокет проигнорирован
tar: /run/user/1000/systemd/private: сокет проигнорирован
tar: /run/user/1000/systemd/notify: сокет проигнорирован
tar: /run/user/1000/inaccessible/sock: сокет проигнорирован
tar: /run/systemd/fsck.progress: сокет проигнорирован
tar: /run/systemd/journal/io.systemd.journal: сокет проигнорирован
tar: /run/systemd/journal/socket: сокет проигнорирован
tar: /run/systemd/journal/stdout: сокет проигнорирован
tar: /run/systemd/journal/dev-log: сокет проигнорирован
tar: /run/systemd/journal/syslog: сокет проигнорирован
tar: /run/systemd/userdb/io.systemd.DynamicUser: сокет проигнорирован
tar: /run/systemd/private: сокет проигнорирован
tar: /run/systemd/notify: сокет проигнорирован
tar: /run/systemd/inaccessible/sock: сокет проигнорирован
tar: /run/udev/control: сокет проигнорирован
tar: /: файл изменился во время чтения
tar: Завершение работы с состоянием неисправности из-за возникших ошибок
Бэкап для Linux, или как создать снапшот
Всем привет! Я работаю в Veeam над проектом Veeam Agent for Linux. С помощью этого продукта можно бэкапить машину с ОС Linux. «Agent» в названии означает, что программа позволяет бэкапить физические машины. Виртуалки тоже бэкапит, но располагается при этом на гостевой ОС.
Вдохновением для этой статьи послужил мой доклад на конференции Linux Piter, который я решил оформить в виде статьи для всех интересующихся хабражителей.
В статье я раскрою тему создания снапшота, позволяющего произвести бэкап и поведаю о проблемах, с которыми мы столкнулись при создании собственного механизма создания снапшотов блочных устройств.
Всех заинтересовавшихся прошу под кат!
Немного теории в начале
Исторически так сложилось, что есть два подхода к созданию бэкапов: File backup и Volume backup. В первом случае мы копируем каждый файл как отдельный объект, во втором – копируем всё содержимое тома в виде некоего образа.
У обоих способов есть масса своих плюсов и минусов, но мы рассмотрим их через призму восстановления после сбоя:
Как же нам взять и сохранить весь том целиком? Само собой, простым копированием мы ничего хорошего не добьёмся. Во время копирования на томе будет происходить какая-то активность с данными, в итоге в бэкапе окажутся несогласованные данные. Структура файловой системы будет нарушена, файлы баз данных повреждены, как и прочие файлы, с которыми во время копирования будут производиться операции.
Чтобы избежать всех этих проблем, прогрессивное человечество придумало технологию моментального снимка – снапшота. В теории всё просто: создаём неизменную копию – снапшот – и бэкапим данные с него. Когда бэкап окончен – снапшот уничтожаем. Звучит просто, но, как водится, есть нюансы.
Из-за них было рождено множество реализаций этой технологи. Например, решения на основе device mapper, такие, как LVM и Thin provisioning, обеспечивают полноценные снапшоты томов, но требуют специальной разметки дисков ещё на этапе установки системы, а значит, в общем случае не подходят.
BTRFS и ZFS дают возможность создавать моментальные снимки подструктур файловой системы, что очень здорово, но на данный момент их доля на серверах невелика, а мы пытаемся сделать универсальное решение.
Предположим, на нашем блочном девайсе есть банальная EXT. В этом случае мы можем использовать dm-snap (кстати, сейчас разрабатывается dm-bow), но тут — свой нюанс. Нужно иметь на готове свободное блочное устройство, чтобы было куда отбрасывать данные снапшота.
Обратив внимание на альтернативные решения для бэкапа, мы заметили что они, как правило, используют свой модуль ядра для создания снапшотов блочных устройств. Этим путём решили пойти и мы, написав свой модуль. Решено было распространять его по GPL лицензии, так что в открытом доступе он доступен на github.
How it works — в теории
Снапшот под микроскопом
Итак, теперь рассмотрим общий принцип работы модуля и более подробно остановимся на ключевых проблемах.
По сути, veeamsnap (так мы назвали свой модуль ядра) – это фильтр драйвера блочного устройства.
Его работа заключена в перехвате запросов к драйверу блочного устройства.
Перехватив запрос на запись, модуль производит копирование данных с оригинального блочного устройства в область данных снапшота. Назовём эту область снапсторой.
А что такое сам снапшот? Это виртуальное блочное устройство, копия оригинального устройства на конкретный момент времени. При обращении к блокам данных на этом устройстве они могут быть считаны либо со снапсторы, либо с оригинального устройства.
Хочу отметить, что снапшот – это именно блочное устройство, полностью идентичное оригинальному на момент снятия снапшота. Благодаря этому мы можем смонтировать файловую систему на снапшоте и произвести необходимый предпроцессинг.
Например, мы можем получить карту занятых блоков от файловой системы. Самый простой способ это сделать – воспользоваться ioctl GETFSMAP.
Данные о занятых блоках позволяют читать со снапшота только актуальные данные.
Также, можно исключить некоторые файлы. Ну, и совсем опциональное действие: проиндексировать файлы, которые попадают в бэкап, для возможности гранулярного рестора в будущем.
CoW vs RoW
Давайте немного остановимся на выборе алгоритма работы снапшота. Выбор тут не особо обширен: Copy-on-Write или Redirect-on-Write.
Redirect-on-Write при перехвате запроса на запись перенаправит его в снапстору, после чего все запросы на чтение этого блока будут уходить туда же. Замечательный алгоритм для систем хранения, построенных на базе В+ деревьев, таких, как BTRFS, ZFS и Thin Provisioning. Технология стара как мир, но особенно хорошо она проявляет себя в гипервизорах, где можно создать новый файл и писать туда новые блоки на время жизни снапшота. Производительность – отличная, по сравнению с CoW. Но есть жирный минус – структура оригинального устройства меняется, а при удалении снапшота надо скопировать все блоки из снапсторы в оригинальное место.
Copy-on-Write при перехвате запроса копирует в снапстору данные, которые должны подвергнуться изменению, после чего позволяет их перезаписать в оригинальном месте. Используется для создания снапшотов для LVM томов и теневых копий VSS. Очевидно, для создания снапшотов блочных устройств он подходит больше, т.к. не меняет структуру оригинального устройства, и при удалении (или аварии) снапшот можно просто отбросить, не рискуя данными. Минус такого подхода – снижение производительности, так как на каждую операцию записи добавляется пара операций чтение/запись.
Поскольку обеспечение сохранности данных для нас основной приоритет, мы остановились именно на CoW.
Пока всё выглядит просто, поэтому давайте пройдёмся по проблемам из реальной жизни.
How it works — на практике
Согласованное состояние
Ради него всё и задумывалось.
Например, если в момент создания снапшота (в первом приближении можно считать, что создаётся он моментально) в какой-то файл будет производиться запись, то в снапшоте файл окажется недописанным, а значит — повреждённый и бессмысленный. Аналогичная ситуация и с файлам баз данных и самой файловой системой.
Но мы же в 21-м веке живём! Есть же механизмы журналирования, предохраняющие от подобных проблем! Замечание верное, правда, есть важное “но”: эта защита не от сбоя, а от его последствий. При восстановлении в согласованное состояние по журналу незавершённые операции будут отброшены, а значит — потеряны. Поэтому важно сместить приоритет на защиту от причины, а не лечить последствия.
Систему можно предупредить о том, что сейчас будет создан снапшот. Для этого в ядре есть функции freeze_bdev и thaw_bdev. Они дёргают функции файловой системы freeze_fs и unfreeze_fs. При вызове первой система должна сбросить кэш, приостановить создание новых запросов к блочному устройству и дождаться завершения всех ранее сформированных запросов. А при вызове unfreeze_fs файловая система восстанавливает своё нормальное функционирование.
Получается, что файловую систему мы можем предупредить. А что с приложениями? Тут, к сожалению, всё плохо. В то время, как в Windows существует механизм VSS, который с помощью Writer-ов обеспечивает взаимодействие с другими продуктами, в Linux каждый идёт своим путём. На данный момент это привело к ситуации, что задача администратора системы самостоятельно написать (скопировать, украсть, купить, etc) pre-freeze и post-thaw скрипты, которые будут подготавливать их приложение к снапшоту. Со своей стороны, в ближайшем релизе мы внедрим поддержку Oracle Application Processing, как наиболее часто запрашиваемую нашими клиентами функцию. Потом, возможно, будут поддержаны и другие приложения, но в целом ситуация довольно печальна.
Где расположить снапстору?
Это вторая встающая на нашем пути проблема. С первого взгляда проблема не очевидна, но, немного разобравшись, увидим, что это та ещё заноза.
Конечно же, самое простое решение — расположить снапстору в RAM. Для разработчика вариант просто отличный! Всё быстро, очень удобно делать отладку, но есть косяк: оперативка — ресурс ценный, и расположить там большую снапстору нам никто не даст.
ОК, давайте сделаем снапстору обычным файлом. Но возникает другая проблема – нельзя бэкапить том, на котором расположена снапстора. Причина проста: мы перехватываем запросы на запись, а значит, будем и перехватывать свои собственные запросы на запись в снапстору. Кони бегали по кругу, по-научному — deadlock. Следом возникает острое желание использовать для этого отдельный диск, но никто ради нас в сервера диски добавлять не будет. Работать надо уметь на том что есть.
Расположить снапстору удалённо — идея отличная, но реализуема в очень уж узких кругах сетей с большой пропускной способностью и микроскопических латенси. Иначе во время удержания снапшота на машине будет пошаговая стратегия.
Значит, надо как-то хитро расположить снапстору на локальном диске. Но, как правило, всё место на локальных дисках уже распределено между файловыми системами, и заодно надо крепко подумать, как обойти проблему deadlock’a.
Направление для раздумий, в принципе, одно: надо как-то аллоцировать у файловой системы пространство, но с блочным устройством работать напрямую. Решение этой проблемы было реализовано в user-space коде, в сервисе.
Существует системный вызов fallocate, который позволяет создать пустой файл нужного размера. При этом фактически на файловой системе создаются только метаданные, описывающие расположение файла на томе. А ioctl FIEMAP позволяет нам получить карту расположения блоков файла.
И вуаля: мы создаём файл под снапстору с помощью fallocate, FIEMAP отдаёт нам карту расположения блоков этого файла, которую мы можем передать для работы в наш модуль veeamsnap. Далее при обращении к снапсторе модуль делает запросы напрямую к блочному устройству в известные нам блоки, и никаких deadlock’ов.
Но тут есть нюанс. Системный вызов fallocate поддерживается только XFS, EXT4 и BTRFS. Для остальных файловых систем вроде EXT3 для аллокации файла его приходится полностью записывать. На функционале это сказывается увеличением времени на подготовку снапсторы, но выбирать не приходится. Опять таки, работать надо уметь на том что есть.
А что, если ioctl FIEMAP тоже не поддерживается? Это реальность NTFS и FAT32, где нет даже поддержки древнего FIBMAP. Пришлось реализовать некий generic алгоритм, работа которого не зависит от особенностей файловой системы. В двух словах алгоритм такой:
Переполнение снапшота
Вернее, заканчивается место, которые мы выделили под снапстору. Суть проблемы в том, что новые данные некуда отбрасывать, а значит, снапшот становится непригоден для использования.
Что делать?
Очевидно, надо увеличивать размер снапсторы. А насколько? Самый простой способ задания размера снапсторы – это определить процент от свободного места на томе (как сделано для VSS). Для тома в 20 TB 10% будет 2TB – что очень много для ненагруженного сервера. Для тома в 200 GB 10% составит 20GB, что может оказаться слишком мало для сервера, интенсивно обновляющего свои данные. А есть ещё тонкие тома…
В общем, заранее прикинуть оптимальный размер требуемой снапсторы может только системный администратор сервера, то есть придётся заставить человака подумать и выдать своё экспертное мнение. Это не соотвествует принципу «It just work».
Для решения этой проблемы мы разработали алгоритм stretch snapshot. Идея состоит в разбиении снапсторы на порции. При этом, новые порции создаются уже после создания снапшота по мере необходимости.
Опять же коротенько алгоритм:
Что делать в других случаях? Пытаемся угадать необходимый размер и создаём всю снапстору целиком. Но по нашей статистике, подавляющее большинство Linux серверов сейчас используют EXT4 и XFS. EXT3 встречается на старых машинах. Зато в SLES/openSUSE можно наткнуться на BTRFS.
Change Block Tracking (CBT)
Инкрементальный или дифференциальный бэкап (кстати, слаще хрен редьки или нет, предлагаю читать тут) – без него нельзя представить ни один взрослый продукт для бэкапа. А чтобы это работало, нужен CBT. Если кто-то пропустил: CBT позволяет отслеживать изменения и записывать в бэкап только изменённые с последнего бэкапа данные.
Свои наработки в этой области есть у многих. Например, в VMware vSphere эта функция доступна с 4-ой версии в 2009 году. В Hyper-V поддержка внедрена с Windows Server 2016, а для поддержки более ранних релизов был разработотан собственный драйвер VeeamFCT ещё в 2012-м. Поэтому, для нашего модуля мы не стали оригинальничать и использовали уже работающие алгоритмы.
Коротенько о том, как это работает.
Весь отслеживаемый том разбит на блоки. Модуль просто отслеживает все запросы на запись, помечая изменившиеся блоки в таблице. Фактически, таблица CBT – это массив байт, где каждый байт соответствует блоку и содержит номер снапшота, в котором он был изменён.
Во время бэкапа номер снапшота записывается в метаданные бэкапа. Таким образом, зная номера текущего снапшота и того, с которого был сделан предыдущий успешный бэкап, можно вычислить карту расположения изменившихся блоков.
Тут есть два нюанса.
Как я сказал, под номер снапшота в таблице CBT выделен один байт, значит, максимальная длина инкрементальной цепочки не может быть больше 255. При достижении этого порога таблица сбрасывается и происходит полный бэкап. Может показаться неудобным, но на самом деле цепочка в 255 инкрементов – далеко не самое лучшее решение при создании бэкап-плана.
Вторая особенность – это хранение CBT таблицы только в оперативной памяти. А значит, при перезагрузке целевой машины или выгрузке модуля она будет сброшена, и опять-таки, понадобится создавать полный бэкап. Такое решение позволяет не решать проблему старта модуля при старте системы. Кроме того, отпадает необходимость сохранять CBT таблицы при выключении системы.
Проблема производительности
Бекап — это всегда хорошая такая нагрузка на IO вашего оборудования. Если на нём и так хватает активных задач, то процесс резервного копирования может превратить вашу систему в этакого ленивца.
Давайте посмотрим, почему.
Представим, что сервер просто линейно пишет какие-то данные. Скорость записи в таком случае максимальна, все задержки минимизированы, производительность стремится к максимуму. Теперь добавим сюда процесс бэкапа, которому при каждой записи надо ещё успеть выполнить алгоритм Copy-on-Write, а это дополнительная операция чтения с последующей записью. И не забывайте, что для бэкапа надо ещё читать данные с этого же тома. Словом, ваш красивый linear access превращается в беспощадный random access со всеми вытекающими.
С этим явно надо что-то делать, и мы реализовали конвейер, чтобы обрабатывать запросы не по одному, а целыми пачками. Работает это так.
При перехвате запросов они укладываются в очередь, откуда их порциями забирает специальный поток. В это время создаются CoW-запросы, которые также обрабатываются порциями. При обработке CoW-запросов вначале производятся все операции чтения для всей порции, после чего выполняются операции записи. Только после завершения обработки всей порции CoW-запросов выполняются перехваченные запросы. Такой конвейер обеспечивает обращения к диску крупными порциями данных, что минимизирует временные потери.
Throttling
Уже на стадии отладки всплыл ещё нюанс. Во время бэкапа система становилась неотзывчивой, т.е. системные запросы ввода-вывода начинали выполняться с большими задержками. Зато, запросы на чтение данных со снапшота выполнялись на скорости, близкой к максимальной.
Пришлось немного придушить процесс бэкапа, реализовав механизм тротлинга. Для этого читающий из образа снапшота процесс переводится в состояние ожидания, если очередь перехваченных запросов не пуста. Ожидаемо, система ожила.
В результате, если нагрузка на систему ввода-вывода резко возрастает, то процесс чтения со снапшота будет ждать. Тут мы решили руководствоваться принципом, что лучше мы завершим бэкап ошибкой, чем нарушим работу сервера.
Deadlock
Я думаю, надо немного подробней объяснить, что это такое.
Уже на этапе тестирования мы стали сталкиваться с ситуациями полного повисания системы с диагнозом: семь бед – один ресет.
Стали разбираться. Выяснилось, что такую ситуацию можно наблюдать, если например создать снапшот блочного устройства, на котором расположен LVM-том, а снапстору расположить на том же LVM-томе. Напомню, что LVM использует модуль ядра device mapper.
В данной ситуации при перехвате запроса на запись, модуль, копируя данные в снапстору, отправит запрос на запись LVM-тому. Device mapper перенаправит этот запрос на блочное устройство. Запрос от device mapper-а снова будет перехвачен модулем. Но новый запрос не может быть обработан, пока не обработан предыдущий. В итоге, обработка запросов заблокирована, вас приветствует deadlock.
Чтобы не допустить подобной ситуации, в самом модуле ядра предусмотрен таймаут для операции копирования данных в снапстору. Это позволяет выявить deadlock и аварийно завершить бэкап. Логика здесь всё та же: лучше не сделать бэкап, чем подвесить сервер.
Round Robin Database
Это уже проблема, подкинутая пользователями после релиза первой версии.
Оказалось, есть такие сервисы, которые только и занимаются тем, что постоянно перезаписывают одни и те же блоки. Яркий пример – сервисы мониторинга, которые постоянно генерируют данные о состоянии системы и перезаписывают их по кругу. Для таких задач используют специализированные циклические базы данных (RRD).
Выяснилось, что при бэкапе таких баз снапшот гарантированно переполнится. При детальном изучении проблемы мы обнаружили недочёт в реализации CoW алгоритма. Если перезаписывался один и тот же блок, то в снапстору каждый раз копировались данные. Результат: дублирование данных в снапсторе.
Естественно, алгоритм мы изменили. Теперь том разбит на блоки, и данные копируются в снапстору блоками. Если блок уже был один раз скопирован, то повторно этот процесс не производится.
Выбор размера блока
Теперь, когда снапстора разбита на блоки встает вопрос: а какого, собственно, размера делать блоки для разбиения снапсторы?
Проблема двоякая. Если блок сделать большим, им легче оперировать, но при изменении хотя-бы одного сектора, придётся отправить весь блок в снапостору и, как следствие, повышаются шансы на переполнение снапсторы.
Очевидно, что чем меньше размер блока, тем больший процент полезных данных отправляется в снапстору, но как это ударит по производительности?
Правду искали эмпирическим путём и пришли в результату в 16KiB. Также отмечу, что в Windows VSS тоже используются блоки в 16 KiB.
Вместо заключения
На этом пока всё. За бортом оставлю множество других, не менее интересных проблем, таких, как зависимость от версий ядра, выбор вариантов распространения модуля, kABI совместимость, работа в условиях бекпортов и т.д. Статья и так получилась объёмной, поэтому я решил остановиться на самых интересных проблемах.
Сейчас мы готовим к релизу версию 3.0, код модуля лежит на github, и каждый желающий может использовать его в рамках GPL лицензии.