GitHub Repo
Paperclipコミュニティがバックアップのフォールバック不具合を報告、復元後にデータベース制約が失われる可能性
10月27日のPaperclipコミュニティの報告によると、pg_dumpのバージョンが一致しない場合、バックアップが警告なくJavaScriptエンジンに切り替わり、復元後にCHECK制約が失われ、一部の一意性ルールが変わる可能性がある。確認時点で問題は未解決で、正式な修正はまだない。

AIエージェント管理プラットフォームPaperclipで、セルフホスト環境のバックアップ完全性に関する報告があった。ユーザーは10月27日、自動バックアップは完了と表示されるものの、復元後にデータベース制約が欠落しており、後続のマイグレーションで既存の制約を削除しようとした際に初めて問題が明らかになったと報告した。報告者は一部を変更した旧版canaryを使用しており、v2026.1023.0のソースコードを確認した結果、該当する処理経路が現在も存在すると述べている。このバージョンに関する判断は、メンテナーによる確認を待っている。問題報告
報告された発生条件は、組み込みのPostgreSQL 18.1とホスト上のpg_dump 16の組み合わせだった。バージョン不一致によりネイティブのエクスポートが失敗した後、Paperclipの自動モードはJavaScriptバックアップエンジンに切り替わったが、フォールバックの理由は記録されなかった。PostgreSQLの公式ドキュメントでは、pg_dumpは自身より新しいメジャーバージョンのサーバーからエクスポートできないと明記されている。そのため、導入時にはデータベースとエクスポートツールの両方のバージョンを確認する必要がある。PostgreSQLドキュメント
報告者による比較では、ソースデータベースにあった66個のCHECK制約がバックアップに含まれず、一部のUNIQUE NULLS NOT DISTINCTが通常のUNIQUEに変わり、タイムスタンプのマイクロ秒精度も失われていた。つまり、復元が成功しても、データの検証ルールが変わっている可能性がある。複数テーブル間のスナップショットに一貫性がないという懸念はコード分析に基づくもので、実測はされていない。実際に確認された差異と混同すべきではない。報告と検証方法
技術面では、エージェントプラットフォームの運用担当者にとって、バックアップファイルが存在し、SQLを読み込めるだけでは、コントロールプレーンを完全に復旧できる証明にはならないことを示している。公式ドキュメントによると、pg_dumpはデータベースが稼働中でも一貫性のあるエクスポートを作成できる。代替エンジンが同じ動作を保つかどうかは、別途検証が必要だ。エクスポートの一貫性に関する説明
エンジニアリングチームは、まず実際に使用されているバックアップエンジンを確認し、隔離環境で復元前後の制約と時間精度を比較するとよい。今後は、メンテナーが最新版への影響範囲を確認するか、また修正によってフォールバック時の警告と復元後の検証の両方が追加されるかを注視する必要がある。現時点では、正式リリースで修正済みとは見なせない。