AI作業・調査メモ (2026/6/20)

AIワークメモ

2026.06.202026.06.26

※AI関連作業のメモ　ディレクトリやファイル名はダミー

ChatGPT Plus 設定サーバ作業・調査メモ

OpenClaw（バージョン 2026.6.8 時点）において、以下のファイルを除外しても問題ない理由は「再生成可能であること」と「データの整合性を守るため」です。

node_modules / ロックファイル（package-lock.json等）： パッケージは後から再インストール（再生成）可能。ファイル数が膨大でバックアップ肥大化の原因になるため除外します。
logs / *.log： アプリの永続データではなく単なる運用履歴。サイズが大きくなりやすく、実行中に常に書き込まれるため除外が適切です。
cache / tmp / temp / *.tmp： 一時データのため自動で再生成されます。古いキャッシュを復元すると逆に不具合の原因になることもあります。
SQLiteの *-wal / *-shm： データベース（WALモード）の補助・一時差分ファイル。実行中に激しく変化するため、これらを直接コピーするとデータの整合性を崩すリスクがあります。

「OpenClawが起動してDBに書き込みを行っている最中」に、tarコマンドでSQLiteファイルを直接コピーする運用について検証が行われ、明確な破損リスク（実在）が証明されました。

検証結果（各80回テスト）：
- DB本体のみコピー： 80回中39回がデータ破損（malformed）、5回が不整合。
- DB本体＋WAL＋SHMを丸ごとコピー： 80回中5回で不整合を検出。
結論： たとえ事前に wal_checkpoint(TRUNCATE) を行ってWALの差分を本体に寄せたとしても、tarでのコピー中にOpenClawが書き込みを行うと、バックアップされたデータベースは高確率で破損します。

OpenClawを停止させずに安全にバックアップを取るため、スクリプトの仕様を「直接コピー」から「SQLiteのOnline Backup API（ホットバックアップ）」を利用する方式へと修正・実行しました。

新方式の流れ：
1. 通常ファイルは rsync で一時ステージング領域へコピー。
2. .sqlite / .db ファイルは直接コピーせず、Pythonの sqlite3.Connection.backup() を用いて、稼働中であっても整合性が保たれたスナップショットを作成。
3. 作成直後に PRAGMA integrity_check; を実行して正常性を確認。
4. *-wal / *-shm を除外した状態で、安全な複製元を tar + gpg（暗号化）で保存。
手動実行による検証結果： アーカイブ内の全7個のSQLiteで integrity_check: ok を確認。不要な一時ファイルや平文データは残らず、世代管理（最古の1世代の剪定）まで正常に動作することを確認済みです。

ご提示いただいたAIとの対話内容は、「OpenClaw（バージョン 2026.6.8）におけるバックアップ処理の効率化と、SQLite導入に伴うデータ破損リスクの改善・検証」に関するものです。

要点を3つのセクションに分けて分かりやすく要約します。

スクリプトで以下のデータを除外しているのは、「再生成が可能であること」と「容量の肥大化・ノイズを防ぐため」です。

cache（キャッシュ）： APIレスポンスやAIのコンテキスト一時データ。復元時に空でも動的に再生成されるため、軽量化のために除外します。
npm（依存パッケージ）： プラグイン用のパッケージ群。設定ファイル（openclaw.json等）さえあれば復元後に自動で再ダウンロードされるため、容量節約（数百MB単位）のために除外します。
*.bak / *.bak.*（古い一時バックアップ）： 過去の設定変更時などに残ったゴミファイル。スクリプト自体が直近7世代を管理しているため、多重に古い世代を詰め込まないよう除外します。
.DS_Store / Thumbs.db（OSの一時ファイル）： MacやWindowsが自動生成する表示用のメタデータ。Linux上で動くOpenClawには不要なノイズのため除外します。

OpenClawのアップデートにより、認証や状態管理が従来のJSON形式からSQLiteデータベース（openclaw.sqlite）に移行しました。これにより、これまでのバックアップ方法にリスクが生じていました。

従来のリスク： OpenClawが起動してデータベースに書き込みを行っている最中に、tarコマンドでファイルを直接コピー（アーカイブ化）すると、バックアップされたデータベースが破損してデータ不整合を起こすリスクがありました。
改善案： 本物のデータベースを直接固めるのではなく、一度SQLiteのコマンドを用いて、起動したままでも一瞬で安全に複製を作れる「オンラインバックアップ機能（ホットコピー）」を挟む構成へのアップデートが提案されました。

提案に基づき、バックアップスクリプトの改修と動作検証が実施されました。

実施した改修内容：
1. 安全なホットバックアップの一時作成： sqlite3の.backup機能を使い、書き込み中であっても不整合が起きない一瞬の複製ファイル（.temp）を安全に切り出す処理を追加。
2. tar時の差し替え（--transformの活用）： 書き込み中で破損リスクのある本来のファイルや一時ファイル（-wal, -shm）は除外。代わりに、作成した複製ファイルをアーカイブ内で本来のopenclaw.sqliteという名前にリネームして格納。
3. 自動クリーンアップ（trap処理）： 処理の正常終了時はもちろん、途中でエラーや中断が発生した場合でも、一時ファイル（.temp）が残らないよう自動削除する堅牢な仕組みを導入。
動作検証の結果： 改修後のスクリプトで作成された暗号化バックアップを実際に復号・展開し、データベースの整合性チェック（PRAGMA integrity_check;）を実行したところ、結果は「ok」となり、データ不整合のない100%安全なバックアップが作れるようになったことが実証されました。