そうだ、バックアップしよう。
えいやっとrsyncでバックアップを取っていたサーバについて、そろそろちゃんとデータ管理しないとつらくなってきました。
変更したファイルの世代管理とかやらんとさすがになぁ、、、と。
で、ちゃんとバックアップ、というと昔々に使ったことがあるBaculaを思い出したのですが、いかんせん10年以上昔の話。
改めていろいろ調べてみようと思います。
バックアップに求める要件
- あるサーバのデータを別のサーバにバックアップしたい
- 変更したファイルについては世代管理をしたい
- 世代間のdiffをとりたい（このファイルの１世代前に戻したいなら、どのスナップショットつかめばいいんだ？）
- 最小のパッケージで動かしたい（管理が面倒になるから）
- スケジューラ（cron）機能はあってもなくてもいい（なければ自分でcron登録するから）
- コンテナバックアップとかいらない。指定のディレクトリのバックアップだけでOK
- ウイルスチェックとかも不要。別途やるから。
- debianで動く
こんなとこですね。
バックアップOSSいろいろ
検索の上の方にある比較サイトを参考にさせていただき、ちょこちょこ試してみました。
1. restic
軽くdocを読んだ感じ、コマンドたたいて使う感じ。
ごてごてしたUIや過度な機能もなく、世代管理（snapshot）は抑えている。
diffもできるっぽい。
aptで入るし依存も少ない。
かなりの好印象、、、なんですが。
使ってみると要検討事項が。
データの流れが想定と逆！
バックアップサーバが１台あって、それがリモートサーバのデータを落としてきて管理、という脳内だったのですが、、
reticは逆で、SFTPでリモートのサーバに「データを押し出す」という動きをします。
バックアップしたいデータを持っているサーバにresticを置いて、データ保存したい外部サーバを指定してresticを動作させるんですね。
当初想定の、バックアップサーバからバックアップ対象のでデータを回収する、という方向で使うには、、
chatgptにご相談してみたところ、sshfs使えばいいじゃんとご回答。
まずバックアップサーバからバックアップ対象サーバに対してsshfsして、バックアップ対象サーバの指定領域がバックアップサーバのローカルディレクトリとして見えるようにする。
で、resticでローカルディレクトリ間のバックアップをさせる、ということです。
バックアップ対象サーバに追加パッケージを入れて汚す、バックアップ対象サーバ側でＣＰＵを使う処理をする、というのは避けたいのでsshfs構成を使いたい気もしますが、逆に余計なsshfs入れずに押し出す方法で使うのも、それはそれできれいに見えますね。
どうしようかな。
スナップショット時にパスワードをかける
なるほどー最近はそうなのかーと受け入れそうになったのですが、、、これcronでバックアップするときどうしよう。
パスワードをファイルに書いておいて、環境変数で渡す方法があるようですが。
気持ち悪い。
元々パスワードかけたいという思いがあったわけではないのですけれど、やはり、気持ちは悪い。
後述のとおり、Baculaとかでも結局コンフィグファイルの中にパスワードを平打ちするんですが、、うーん。。
またchatgptとご相談してみたのですが、こんな方法をご提案いただきました。
gpg -q --decrypt /path/to/restic-password.gpg | restic --password-file /dev/stdin backup ~/remote_mount
gpg自体のパスワードどうする？という話。
gpg以外の方法に考えを広げるとTPMデータを使うなどのひねりはききそうな気はしますが、やりすぎかな。。
一旦置いといて、別のを見てみます。
2. Bacula
https://www.bacula.org/
商用版とCommunity Editionを併設する形になってるんですね。
調べてから投稿まで結構立っちゃったのですが、、2025年の春頃に調べた結果。
linux（debian 12で調査）のレポジトリでは付されているのは9.6.7。
一方Baculaサイトで公開されている最新版は、、、15!?
しかもEnterprise Editionまで見ると18。。
乖離がすさまじいなぁ、、、
とりあえずcommunityで15と9を比べてみよう、、と思ったのですが。
https://packages.debian.org/search?keywords=bacula
現状のdebian13(trixie)では15になるようです。
以下は、当時、debian12 + ver.9で試してみたときのメモ。
ver.9をインストールしてみる
user01@bkup:~$ sudo apt install bacula
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
bacula-bscan bacula-client bacula-common bacula-common-pgsql bacula-console bacula-director bacula-director-pgsql bacula-fd bacula-sd bacula-server bsd-mailx dbconfig-common dbconfig-pgsql exim4-base
exim4-config exim4-daemon-light libcommon-sense-perl libevent-2.1-7 libgnutls-dane0 libidn12 libjson-perl libjson-xs-perl libllvm14 liblockfile1 liblzo2-2 libpq5 libsensors-config libsensors5
libtypes-serialiser-perl libunbound8 libxslt1.1 libz3-4 mt-st mtx postgresql postgresql-15 postgresql-client postgresql-client-15 postgresql-client-common postgresql-common psmisc ssl-cert sysstat
Suggested packages:
gdb bacula-doc gawk dds2tar scsitools sg3-utils exim4-doc-html | exim4-doc-info eximon4 spf-tools-perl swaks dns-root-data lm-sensors postgresql-doc postgresql-doc-15 isag
The following NEW packages will be installed:
bacula bacula-bscan bacula-client bacula-common bacula-common-pgsql bacula-console bacula-director bacula-director-pgsql bacula-fd bacula-sd bacula-server bsd-mailx dbconfig-common dbconfig-pgsql
exim4-base exim4-config exim4-daemon-light libcommon-sense-perl libevent-2.1-7 libgnutls-dane0 libidn12 libjson-perl libjson-xs-perl libllvm14 liblockfile1 liblzo2-2 libpq5 libsensors-config libsensors5
libtypes-serialiser-perl libunbound8 libxslt1.1 libz3-4 mt-st mtx postgresql postgresql-15 postgresql-client postgresql-client-15 postgresql-client-common postgresql-common psmisc ssl-cert sysstat
0 upgraded, 44 newly installed, 0 to remove and 0 not upgraded.
Need to get 55.3 MB of archives.
After this operation, 216 MB of additional disk space will be used.
Do you want to continue? [Y/n]
RDBのpostgresにメールのexim。
結構入るなぁ、、
postgresのDB初期化も併せて実施できるので、お任せします。
パスワードも、インストーラに従えば、適切にパスワード自動生成してコンフィグに書き込んでくれる。
バックアップ対象などは自分で設定。
Bacula ver.9をつかってみる
以下で概要を勉強させていただいて、つかってみると。。
（ざっと構成を理解するには分かりやすかったのですが、さすがに８年前。。いろいろ変わってる。）
https://gihyo.jp/admin/serial/01/bacula/0002
基本的に、コンフィグファイルに入れた設定で、スケジュールに従って、対象サーバの対象領域のデータを、指定したRDBに保存する。
都度実行したいときや復元するときはbconsoleという対話型コマンドで処理。
ただし、/usr/sbin配下に配置されるので、sudoしないとたたけないてとこが備忘録でしょうか。
で、バックアップ対象サーバ側にもエージェント（bacula-fd）を入れるんですね。
スナップショット間差分機能は、、ざっと見は見つからず。
脱線 バックアップサーバのバックアップ
一応視野に入れておきます。
素直に考えるなら、Baculaなら保存先のデータベース（サーバ）の２つ目を用意して、そちらに対して穂損するJobを追加する、でしょうか。
注意点としては、Bacula自体のコンフィグ（特にパスワード）も併せて厳密にバックアップすること。
それないとメインのBaculaがトラブった際に、別途立てたBaculaでレスキューとかできなくなっちゃうから。。
あるいは、
Postgres自体のバックアップをするなど、バックアップサーバ自体のバックアップ。
まだるっこしくはあるのですが、必然的に使うアーキテクチャが変わるので、「Postgresの致命的なバグで同一構成のサーバのデータが全滅」みたいなケースは防げます。
また、サーバ複数立てるよりはシンプルに組めるかなーという感触。
今回は後者で考えてみます。
で、どれつかう？
すごくシンプルで好感が持てるresticと、正統派でわかりやすいbaculaで悩みます。
通信の方向については、言い方帰ると「どこからログインさせるかの管理」です。
素直に考えるとバックアップサーバの方がセキュアな内側になるので、内側⇒外側の通信の流れの方が制御しやすい。
ランサムなどの横展開を考えると、外⇒内の通信パスが空いているのは怖い。
といっても今回の構成はそこまで厳密にする気はないので、「一部のサーバ群が共通で使うバックアップ領域」みたいに考えてもいい。
スナップショット間差分は重宝する気がするので、ある方がいい。
⇒今回はresticで行ってみようかなと思います。
使い込んでみてまた何か気づきがあったら追記ということで。
今日はここまで。