Введение

Когда в инфраструктуре десятки сервисов и баз данных разных типов, ручное резервное копирование превращается в кошмар.

Один сервер использует PostgreSQL, другой — MySQL, третий — MongoDB, и для каждого нужны свои команды (pg_dump, mysqldump, mongodump) и свои скрипты.

Проект Dumper решает эту проблему он объединяет все типы баз в один универсальный инструмент.

Dumper написан на Go и работает через CLI, конфигурация задаётся в YAML — поэтому его легко встроить в cron, CI/CD pipelines, GitHub Actions или Docker-окружение.

Преимущества Dumper

  • Мульти-СУБД — PostgreSQL, MySQL, MongoDB и другие.

  • SSH-подключения — можно делать дампы с удалённых серверов.

  • Гибкие шаблоны имён файлов — удобно для хранения и автоматизации.

  • Автоматическая архивация и удаление старых дампов.

  • Простая интеграция с cron / CI / Jenkins / GitLab Runner.

Пример: резервное копирование трёх баз данных

У нас три БД на разных серверах:

Сервер

СУБД

Назначение

Хост

Порт

db-prod-pg

PostgreSQL

Продакшен

10.1.1.10

5432

db-stage-mysql

MySQL

Стейджинг

10.1.1.20

3306

db-analytics-mongo

MongoDB

Аналитика

10.1.1.30

27017

Конфигурация Dumper

settings:
  template: "{%srv%}_{%db%}_{%date%}_{%time%}"
  archive: true
  remove_dump: true
  format: "dump"
  dir_dump: "/opt/backups/dumps"
  dir_archived: "/opt/backups/archived"
  location: "server"

servers:
  prod-pg:
    name: "db-prod-pg"
    host: "10.1.1.10"
    port: 22
    user: "ubuntu"
    private_key: "~/.ssh/id_rsa"
    is_passphrase: false

  stage-mysql:
    name: "db-stage-mysql"
    host: "10.1.1.20"
    port: 22
    user: "deployer"
    password: "mysqlpass"

  analytics-mongo:
    name: "db-analytics-mongo"
    host: "10.1.1.30"
    port: 22
    user: "admin"
    private_key: "~/.ssh/id_backup"
    is_passphrase: false

databases:
  production_pg:
    name: "prod_db"
    user: "postgres"
    password: "pgpass"
    server: "prod-pg"
    driver: "psql"
    format: "plain"

  staging_mysql:
    name: "staging"
    user: "mysqluser"
    password: "mysqlpass"
    server: "stage-mysql"
    driver: "mysql"
    format: "sql"

  analytics_mongo:
    name: "analytics"
    user: "root"
    password: "mongo123"
    server: "analytics-mongo"
    driver: "mongo"
    format: "bson"
    options:
      auth_source: "admin"
      ssl: true

Запуск вручную

Для проверки можно выполнить дамп одной базы:

./dumper --config ./config.yaml --db production_pg

Или всех баз сразу:

./dumper --config ./config.yaml --all

Или выбрать вручную

./dumper --config ./config.yaml

Автоматизация через cron

Добавим ежедневный бэкап в /etc/crontab:

0 3 * * * root /usr/local/bin/dumper --config /opt/dumper/config.yaml --all >> /var/log/dumper.log 2>&1

Советы и полезные рекомендации

  • Убедитесь, что SSH-ключ настроен и доступ к серверу есть без запроса пароля (или используйте ssh-agent).

  • Проверьте права доступа: пользователь должен иметь права на выполнение дампа (например, pg_dump для PostgreSQL).

  • Мониторьте свободное место на диске: если регулярно делать резервные копии и не удалять старые, очень быстро наберётся объём.

  • Используйте шаблон template так, чтобы имя файла отражало дату / время — удобно для поиска и архивирования.

  • Тестируйте восстановление: резервная копия — не ценна, пока не уверены, что её можно восстановить.

  • Учитывайте чувствительную информацию: файл конфигурации содержит пароли и ключи — храните его в безопасном месте или ограничьте доступ.

  • Ознакомьтесь с форматами: например, MongoDB может использовать формат bson, PostgreSQL — plain, dump, tar.

Заключение

Dumper — простой инструмент для резервного копирования баз данных, особенно если у вас несколько разных серверов и СУБД. Он позволяет стандартизировать процесс, минимизировать ручные шаги и интегрировать резервное копирование в автоматизированные рабочие процессы.

Комментарии (8)


  1. chemtech
    23.10.2025 14:29

    На s3 может складывать лампы и восстанавливаться из s3?


    1. elkirrs Автор
      23.10.2025 14:29

      Нет, только в той среде где запускается dumper. Ваша идея хорошая. Возможно в следующих версиях появится данная возможность.


  1. m1skam
    23.10.2025 14:29

    Когда в инфраструктуре десятки сервисов и баз данных разных типов, ручное резервное копирование превращается в кошмар.

    Идея хорошая, всяческих успехов вам, но, лично мое мнение, что если у вас десятки баз данных, то лучше использовать специализированные инструменты, проверенные временем, которые умеют как минимум в инкрементное резервное копирование, а так же не ограничены набором флагов.

    PS: А что за формат dump для postgres, описанный в вашем репозитории? В официальной документации только plain, custom, directory и tar.


    1. HomeMan
      23.10.2025 14:29

      switch data.DumpFormat {
      	case "dump":
      		formatFlag = "-Fc"
      		ext = "dump"
      	case "tar":
      		formatFlag = "-Ft"
      		ext = "tar"
      	}

      Вот этот формат


      1. masaj07
        23.10.2025 14:29

        -Fc - custom


  1. stasonuu
    23.10.2025 14:29

    https://github.com/gobackup/gobackup - вот отличный софт.
    Поддерживает базы:

    • MySQL

    • PostgreSQL

    • Redis

    • MongoDB

    • SQLite

    • Microsoft SQL Server

    • InfluxDB

    • MariaDB

    • etcd

    • Firebird

    А так же умеет хранить в S3, локально, ftp, итд


    1. Sleuthhound
      23.10.2025 14:29

      А восстанавливать им можно из этого дампа?

      Иначе какой смысл инструменты который умеет делат дампы (бэкапы), но не умеет из него восстанавливать


      1. stasonuu
        23.10.2025 14:29

        Это планировщик бэкапов для баз данных. Восстанавливайте стандартными утилитами.