Comments 5
В качестве развлечения и изучения чего то нового - прикольно. Но в качестве решения даже для одного сервера, я наверное буду использовать проверенную временем Bacula или Bare OS. Не потому что я не доверяю вашему решению, а потому что больше опций и возможностей.
Нет параметров для вызова утилит резервного копирования баз данных, у того же pg_dump их достаточно много и я хотел бы ими управлять (-с -С -F -x -s и тд)
На определенных объемах, логичнее становится ежедневно делать инкрементальный бэкап и еженедельно полный. К примеру, если у вас сайт куда загружают большое кол-во pdf или картинок, сам по себе мощный сервер не нужен, потому что обращений мало, но весит все это много, а сжимается плохо и легко за пару лет, бекап переваливает за тцать гигабайт, каждый день создавать такой архив и переливать его в s3 - такое себе. И еще нужно следить, что бы на диске всегда было больше 50% свободного места, а то может случиться сюрприз )
Жизненный цикл хранения бекапов, так же может быть более сложным чем "храним за последние 14 дней", например "Храним ежедневные бекапы за последние 2 недели и еженедельные бекапы за последние 2 месяца".
Изучение новых языков программирования, а особенно таких сложных, это весьма похвально.
Но зачем все же делать тулзу в той области, где уже и так существует большое количество развитых утилит? Где фактически заранее известно что нет шансов, что этот код будет комуто полезен практически?
Тот же restic: поддерживает из коробки штук 10 бекендов (и еще штук 40 через rclone, в котором реализовали интерфейс его хранилища), дедупликацию, шифрование, функционал append only, монитирование бекапов по fuse. Для того чтобы пользователь захотел только начать пользоваться ващей утилитой, вам, увы, придется реализавать большую часть из этого.
В первую очередь это важно и полезно мне, и то, что существуют аналоги не означает, что нужно сложить лапки и писать то, чего ещё нет.
Restic же, действительно предоставляет и способы хранения и удобное хранение только изменений а-ля git, но он хранит только файлы, он не делает бэкапы баз данных, например в докере. Да, он может забэкапить весь Docker Volume БДшки, но это не лучший выход и не всегда корректно восстанавливается.
В общем, буду и дальше развивать программу в процессе изучения Rust и посмотрим, что будет. Даже если пользоваться буду только я и пара моих знакомых, этого уже достаточно.
Спасибо за комментарий!
А что плохого в том чтобы не сохранять неизменившиеся данные 2 и более раза? Это же никак не ограничивает область применения программы (а если вы используете в качестве железки для хранения продвинутую SAN с дедупликацией, то она сделает это за вас невидимо и совершенно так же (сославшись несколько раз по хешу на один чанк), оставляя лишь иллюзию избыточного хранения нескольких копий). Вместо того чтобы заливать одно и то же повторно, нагружая каналы и диски, можно потратить ресурсы на то чтобы перепроверить то что было залито ранее (сравнить хеши) например находясь поближе к хранилищу (=дешевле). А тестовое разбекапливание в обоих случаях никто не отменял.
Это верно, что для бекапа баз лучше всего подходят специальные программы. В случае postgres и mysql - это скорее всего wal-g для pitr через непрерывное архивирование wal.
А вот для архивирования БД не понимаю чем не угодили комбинации из 2 программ pg_dump | restic backup --stdin или restic dump | psql для архивирования и восстановления соответственно, при использовании которых еще и 2ное место под дамп не надо резервировать (программы написаные по философии unix должны уметь работать совместно с другими программами). Покрайней мере я делаю так уже годы и не вижу никаких проблем. Еще делаю рестиком файловые бекапы с lvm снепшотов и тоже без проблем.
Кажется что чем менее программа заточена под конкретное применение (не имеет списка никаких поддерживаемых источников кроме стандартных stdin и файлов) тем более это расширяет её область применения и соотвественно потенциальный пользовательский охват. Так же делает пользовательскую базу более профессиональной.
Алсо: ни на чем не настаиваю. Peace. :)
Создание бэкап-утилиты ReBack на Rust: от проблем до решения