IOBackup помогает не просто делать резервные копии, а видеть весь процесс: какие данные сохраняются, где лежат копии, прошла ли проверка, когда была ошибка и какие старые копии уже удалены по правилам.
IOBackup помогает видеть весь процесс резервного копирования: какие данные сохраняются, где лежат копии, прошла ли проверка, когда была ошибка и какие старые копии удалены по правилам хранения. Агент работает на Linux‑сервере, а задания описываются в YAML и запускаются через CLI или API.
В YAML и API этим шагам соответствуют, в том числе, термины source, streaming, checksum, destination, manifest, retention и уведомления (notifications / webhook). Подробнее см. техническую документацию.
На схеме показан один полный запуск задания резервного копирования. Задание, или job, описывает, что нужно сохранить, откуда брать данные, куда отправить копию и как долго её хранить.
Агент читает данные из указанного источника: базы данных, каталога с файлами или другого поддерживаемого сервиса. Данные передаются потоково — по мере чтения. Это снижает нагрузку на сервер и позволяет не держать всю копию в памяти или во временном каталоге.
Дальше IOBackup выполняет служебную обработку: считает контрольные суммы, готовит результат к записи в хранилище и фиксирует технические данные о запуске.
Результат записывается в выбранное хранилище: локальный каталог, S3-совместимое объектное хранилище или удалённый узел по SSH. Вместе с копией сохраняется manifest — «паспорт» резервной копии: по нему можно понять состав, проверить checksum и связать копию с конкретным запуском. Если служебная база агента будет потеряна, sidecar manifest помогает понять, что находится в хранилище.
После успешной записи применяются правила хранения. Например, можно оставить только последние успешные копии или удалить копии старше заданного срока. Это снижает риск переполнения хранилища и убирает ручную очистку.
Каждый запуск фиксируется в истории: когда он начался, чем закончился, какие задачи выполнились успешно и где возникла ошибка. Эти данные можно использовать для отчётов, расследования инцидентов и контроля регулярности резервного копирования.
События об успешном или неуспешном запуске можно отправлять во внешние системы через webhook, а технические показатели отдавать в мониторинг. Так команда быстрее узнаёт о проблеме и видит статус резервного копирования на дашбордах.
Про технические имена. В YAML и API тем же этапам соответствуют, в частности, source, streaming, checksum, destination, manifest, retention и notifications. Подробности — в технической документации.
Типичная проблема: резервные копии формально создаются, но никто не видит единой картины — какие задания выполнялись, где была ошибка, какие копии проверены и сколько места они занимают. В итоге проблемы часто обнаруживаются только в момент аварии или восстановления.
IOBackup переводит резервное копирование из набора разрозненных скриптов в управляемый процесс: задания описываются единообразно, запуски сохраняются в истории, результат можно проверять, старые копии удаляются по правилам, а события отправляются в мониторинг.
Проверка после запуска помогает убедиться, что резервная копия действительно создана, доступна для чтения и относится к нужному заданию. Это снижает риск обнаружить проблему только в момент восстановления. Подробнее в документации — как настраивается проверка и политики после запуска.
История запусков, логи задач, webhook-уведомления и метрики Prometheus помогают раньше заметить сбои. Для эксплуатации это один понятный регламент вместо множества отдельных скриптов на разных серверах.
Правила хранения удаляют старые копии из выбранного хранилища и оставляют след в истории операций. Это помогает проходить внутренние проверки, разбирать инциденты и постепенно подключать новые источники данных и места хранения через модульную архитектуру.
Поддержка сценариев развивается постепенно: базовые варианты filesystem/local наиболее простые, а базы данных, S3/SSH и специальные источники стоит проверить в вашей инфраструктуре. Актуальный статус зрелости — в status matrix.
IOBackup можно подключать к разным типам данных: от обычных каталогов на сервере до баз данных, LDAP-каталогов и конфигураций Docker Compose.
Продукт построен модульно: новые типы источников и хранилищ можно добавлять без смены общей логики. Ниже — набор, поддерживаемый в текущей версии.
Перед промышленным использованием конкретного источника или хранилища лучше сделать пилотный backup/verify на тестовых данных и свериться со status matrix (maturity и known gaps).
Имена типов в YAML и API:
filesystem, postgres, mysql, clickhouse, vault, openldap, docker_compose
s3);ssh).Если на сервере нет нужных утилит для дампа или работы с S3, IOBackup может запускать отдельные операции через Docker-based runner. Это помогает не устанавливать все инструменты напрямую в систему, но требует доступного Docker-окружения.
Каждый запуск проходит один и тот же понятный цикл: описать задание, запустить его, сохранить копию, проверить результат и получить статус.
В YAML указывается источник данных, место хранения, формат копии и правила хранения старых версий.
Задание можно запустить вручную через CLI или HTTP API. В текущей версии запуск контролирует оператор или внешняя система автоматизации.
Агент читает данные потоково, считает контрольные суммы, сохраняет результат в выбранное хранилище и добавляет manifest-файл с описанием копии.
IOBackup может выполнить проверку после успешного запуска и применить правила хранения: например, удалить устаревшие копии или оставить только заданное количество последних успешных запусков.
История запусков, логи, метрики и webhook-события показывают, что произошло: копия создана, проверка прошла успешно или возникла ошибка.
Доступ к API можно защитить Bearer-токенами, TLS/mTLS и ограничением частоты запросов. Это снижает риск несанкционированного запуска или просмотра заданий.
Пароли баз данных, ключи S3 и токены webhook не нужно хранить прямо в YAML-заданиях. Их можно передавать через переменные окружения или отдельные файлы с ограниченными правами доступа, а также использовать HashiCorp Vault как хранилище секретов.
IOBackup маскирует чувствительные поля в API и уведомлениях (redaction). Шифрование самих backup‑артефактов перед записью в хранилище — отдельное направление развития и не должно восприниматься как уже доступная функция текущей версии.
IOBackup хранит историю запусков, проверок и служебных операций в локальной metadata DB. Для неё предусмотрены политики хранения и команды обслуживания: metadata check/backup/export/compact. Часть очистки уже выполняется, а более детальные per‑type политики будут развиваться в следующих версиях.
IOBackup планируется распространять как стандартные Linux-пакеты через APT-репозиторий для Debian/Ubuntu и YUM/DNF-репозиторий для RHEL-совместимых систем.
Для Debian и Ubuntu предполагается установка из APT-репозитория. Пользователь сможет поставить агент и CLI стандартными средствами системы, без ручной сборки проекта из исходного кода.
Для AlmaLinux, Rocky Linux, RHEL и других совместимых систем предполагается установка через YUM/DNF. Пакеты должны поддерживать подпись, обновление и управление конфигурацией стандартными средствами дистрибутива.
Пакет должен устанавливать бинарники агента и CLI, systemd-unit для запуска сервиса, пример конфигурации и пример env-файла. Версия пакета должна соответствовать версии релиза IOBackup.
После установки IOBackup лучше внедрять постепенно: сначала проверить несколько критичных сценариев, затем расширить покрытие и только после этого закрепить регламенты эксплуатации.
Panel Lite — лёгкий веб-интерфейс для просмотра состояния IOBackup. Через него можно видеть задания, историю запусков, артефакты, результаты проверок и логи задач. Панель не требует отдельной базы данных и может раздаваться рядом с API агента через reverse proxy.
Это панель просмотра одного агента, а не система централизованного управления fleet‑ом — central server остаётся в планах.
В текущей версии уже есть агент, CLI/API, Panel Lite, история запусков, manifest и контрольные суммы, правила хранения, webhooks и Prometheus‑метрики. Также заложены foundation‑модели для будущих функций: стабильные ID, revisions, snapshots, locks, metadata maintenance и capabilities/facts. Restore, scheduler, central server, client‑side encryption, verify‑worker и incremental backup остаются планируемыми направлениями.
Ниже перечислены функции, которые планируется развивать в следующих версиях IOBackup. Они описывают направление продукта и не должны восприниматься как уже доступные возможности текущей версии.
Планируется добавить запуск восстановления через веб-интерфейс, чтобы оператор мог выбирать резервную копию и выполнять восстановление без ручной сборки команд в консоли.
Планируется поддержать перенос резервных копий между серверами, хранилищами и резервными площадками.
Планируется единая панель для управления агентами, заданиями, расписаниями, доступом и статусами по нескольким серверам.
Планируется поддержка шифрования резервных копий перед сохранением в хранилище, чтобы снизить риск доступа к данным при компрометации места хранения.
Планируется изолированная среда для проверки резервных копий: автоматическое разворачивание, проверка содержимого и подтверждение, что данные пригодны для восстановления.
Планируется режим, при котором IOBackup сохраняет только изменения после предыдущего успешного запуска. Это должно ускорить копирование и снизить расход места в хранилище.
Планируется поиск по файлам, версиям и артефактам внутри резервных копий без ручного просмотра каталогов и manifest-файлов.
Планируется механизм шаблонов, чтобы быстро создавать типовые задания резервного копирования для новых серверов и сервисов.