バックアップ・復旧・災害復旧
unmask を導入したホストを控えて、別のホストで戻すための運用手順です。
以下のパスはすべて既定値なので、実際の値は /etc/unmask/config.yml を確認してください。
何を控えるか（と、その理由）
| 対象 |
パス（既定） |
なぜ要るか |
| config.yml |
/etc/unmask/config.yml |
bv_secret と captcha_secret_base、DB 接続情報を持ちます。bv_secret を失う・変えると、発行済みの _bv cookie がすべて無効になり、いま訪れている人が一斉に再 challenge を受けます（停止はしませんが challenge が跳ねます）。DB の認証情報もここにあります。 |
| DB |
SQLite: /var/lib/unmask/unmask.sqlite（+ -wal / -shm）
MariaDB: unmask_* スキーマ |
管理ユーザー、ban、イベント（= stats）、毎時集計。 |
| ban file |
config の nginx.ban_file |
file ベースの ban を nginx が直接読んで効かせます。外で書き換えた場合、DB だけからは復元できません。 |
控えなくてよいもの（自動で再生成されます）:
/var/lib/unmask/nginx/*.inc（unmask render-nginx が作り直す）、
community-bans-*.map（feed から再取得）、配置済みの
ngx_http_unmask_module.so（再インストール / nginx 起動時に再配置）。
バックアップ
# 1. config + ban file（軽いのでこまめに）
install -d -m 0700 /backup/unmask
cp -a /etc/unmask/config.yml /backup/unmask/
cp -a "$(awk '/ban_file:/{print $2}' /etc/unmask/config.yml)" /backup/unmask/ 2>/dev/null || true
# 2a. SQLite — daemon を止めずに一貫したスナップショット
sqlite3 /var/lib/unmask/unmask.sqlite ".backup '/backup/unmask/unmask.sqlite'"
# 2b. MariaDB
mysqldump --single-transaction --routines unmask_<db> > /backup/unmask/unmask.sql
--single-transaction（InnoDB）はロックせずに一貫したダンプを取ります。SQLite の
.backup は書き込み中でも安全で（read lock をかけてページ単位でコピーする）、稼働中の
SQLite ファイルを素の cp で取ると WAL が途切れた状態を拾うことがあります。
復旧
- バックアップを取ったときと同じ unmask のバージョンを入れます（
unmask version）。
config.yml を先に戻します。これで bv_secret が保たれ、発行済みの _bv cookie がそのまま通り、訪問者を一斉に再 challenge せずに済みます。- DB を戻します:
- SQLite: daemon を止め、ファイルを戻し、起動。
- MariaDB:
mysql unmask_<db> < /backup/unmask/unmask.sql。
- ban file を設定したパスに戻します。
unmask render-nginx && nginx -t && systemctl reload nginx（SysVinit は service nginx reload）。- admin サービスを起動 / 再起動し、
unmask doctor と curl -sf http://127.0.0.1:9477/unmask/healthz で確認します。
DB ドライバの切り替え（SQLite ⇄ MariaDB）
unmask にドライバ間の自動データ移行はありません。やり方は 2 通りです。
まっさらに切り替える（stats の履歴が惜しくないなら、これが楽）
config.yml の db.driver（と MariaDB の接続情報）を新しいドライバに向け、
unmask migrate でそちらに schema を作り、再起動します。新しい DB は空から始まり、
過去のイベント / stats は残せず、管理ユーザーと ban は作り直し（または手動でインポート）になります。
stats が貯まる前の早い段階でやるのが楽です。admin の再設定ウィザード（設定済みなら
/admin/setup/）でも UI から同じことができます。
データを残す（手作業）
古いドライバをダンプし、SQL 方言の差（SQLite ↔ MariaDB の型・クォート）を手で直して、
unmask migrate が作った schema に読み込みます。バージョン依存で、1 コマンドで済む経路は
用意していません。終わったら行数を突き合わせて確認してください。
アップグレードと確認
unmask migrate（daemon 起動時に走るほか、手動でも実行可能）は冪等で何度でも再実行できます。
これが、DDL がトランザクションにならない MariaDB（ALTER / CREATE が都度 auto-commit され、ロールバックできない）でも安全な理由です。
列・テーブルの追加はすべて「あるか確認してから適用」で、各 ALTER の前に
hasColumn / hasTable を見て、土台は CREATE TABLE IF NOT EXISTS です。
途中で中断したマイグレーションも、unmask migrate を実行し直せば、適用済みのステップは検出されて飛ばされ、復旧します。
注意（MariaDB のみ）: アップグレード後の初回起動で 1 度だけ走る unmask_cookie_minute の
schema v2 へのコピーは、トランザクションで囲っていません。コピーの途中で中断して再実行すると、
cookie-minute の stats 行を一部二重に数えることがあります。影響は stats の水増しだけで、データ損失や停止はありません。
アップグレード後の初回起動を中断せず最後まで通せば避けられます。SQLite はこの影響を受けません
（マイグレーションが 1 つのトランザクションで走り、まとめてロールバックされます）。
確認
unmask doctor # DB 疎通 + schema + config チェック
unmask version # 戻したバイナリのバージョン確認