Комментарии 11
На s3 может складывать лампы и восстанавливаться из s3?
Когда в инфраструктуре десятки сервисов и баз данных разных типов, ручное резервное копирование превращается в кошмар.
Идея хорошая, всяческих успехов вам, но, лично мое мнение, что если у вас десятки баз данных, то лучше использовать специализированные инструменты, проверенные временем, которые умеют как минимум в инкрементное резервное копирование, а так же не ограничены набором флагов.
PS: А что за формат dump для postgres, описанный в вашем репозитории? В официальной документации только plain, custom, directory и tar.
https://github.com/gobackup/gobackup - вот отличный софт.
Поддерживает базы:
MySQL
PostgreSQL
Redis
MongoDB
SQLite
Microsoft SQL Server
InfluxDB
MariaDB
etcd
Firebird
А так же умеет хранить в S3, локально, ftp, итд
Предлагаю пару идей:
База данных очень часто работает в каком-нибудь контейнере и инструменты для создания резервных копий тоже находятся в контейнере (например pg_dump/pg_restore). Предусмотрите это в своей утилите: нужно не просто зайти по ssh, но ещё и зайти в контейнер. В случае с той же монгой- не только зайти в контейнер, но ещё и volume примонтировать.
Было бы круто иметь возможность пароли хранить не только в yaml, но и брать их из какого-нибудь vault - Keychain/Seahorse/...
Когда в инфраструктуре десятки сервисов и баз данных разных типов,
... обычно уже понимаешь, что "dump" != "backup". Вот прям совсем-совсем "не". "Не годится", можно даже сказать. А в остальном - да-да, без "данных" и "нагрузки" можно пользоваться. Наверное - даже удобно...

Dumper: единый инструмент для резервного копирования баз данных