NASアプリのメタデータに対するクラウド同期の除外設定を最適化するには、どのファイルが移行可能な復旧状態で、どのファイルが再生成可能、マシン固有、ロック中、またはトランザクション上安全にコピーできないものかを判断します。
「隠しファイルをすべて除外する」や「アプリデータディレクトリ全体を同期する」といった単一のルールを作成しないでください。ドットファイルには重要な設定が含まれる場合がある一方、通常のファイルに見える catalog.db は稼働中のデータベースであり、一般的な双方向同期では通常のドキュメントとして扱うべきではありません。まず各パスを復元時の役割で分類し、その一覧をもとに除外設定を作成します。
復旧時の役割ごとにアプリのメタデータを一覧化する
各アプリケーションディレクトリについて、内容を正規のユーザーデータ、移行可能な設定、データベース状態、生成済みインデックス、キャッシュ、サムネイル、ログ、一時ファイル、ロック、秘密情報、またはマシン固有のメタデータに分類します。アプリケーションがそれを再生成できるか、復元時に別のファイルやデータベースとの整合性が必要かも記録してください。
2026年の隠しデータを役割別に分類する記事では、隠しファイル、一時ファイル、OSメタデータ、ロックされたアプリケーション状態、ユーザーが作成したドットファイルを一つのカテゴリとして扱わずに区別しています。これはNASのアプリフォルダにも適したモデルです。
クラウド同期の対象範囲と除外設定に関するZimaSpaceの関連トラブルシューティング記事では、運用上の境界が示されています。「完了」と表示されるタスクは、設定されたルールの範囲内で完了したという意味です。そのため、除外設定は後から欠落ファイルを見て推測するのではなく、文書化しておく必要があります。
再生成可能な状態と変更頻度の高い状態を先に除外する
除外の候補として適しているのは、不要なキャッシュ、生成済みサムネイル、一時的なトランスコード用ディレクトリ、ブラウザ型のキャッシュツリー、ロックファイル、ソケットファイル、パッケージのダウンロードキャッシュ、復旧価値のない詳細なローテーションログなどです。これらを削除すると、項目数、競合リスク、クラウドAPIの処理量、不要なリモートストレージ使用量を減らせます。
除外の候補として適しているのは、不要なキャッシュ、生成済みサムネイル、一時的なトランスコードファイル、ロックファイル、パッケージキャッシュ、復旧価値のない詳細なログなどです。アプリケーションが安全に再生成できることを確認してから除外してください。
名前に cache が含まれている、またはドットで始まっているという理由だけでディレクトリを除外しないでください。ユーザーが作成したメタデータ、検索タグ、アルバム構造、認証情報を失わずにアプリケーションが再構築できることを確認します。
稼働中のデータベースを一般的な双方向同期から除外する
同期クライアントが読み取っている間にも、稼働中のデータベースは変更される可能性があります。2026年に行われた稼働中のSQLiteデータベースのコピーに関する検証では、ファイル単位のコピーによってコミット済みのWALデータが欠落したり、一貫性のない状態が取得されたりする可能性が示されています。一般的な双方向同期にはトランザクション認識機能がないため、データベースの復旧にはアプリケーション対応のダンプ、スナップショット、またはサポートされたバックアップ経路を使用してください。
CloudScopeの分析では、ロックされているアプリケーションファイルや継続的に変更されるアプリケーションファイルは、ファイル名が通常のものに見えても、スキップされたり、繰り返し競合したりする可能性があると指摘されています。トランザクション状態については、「アプリを終了した後に同期された」というだけでは、整合性のある復旧ポイントを作成するアプリケーション対応のダンプ、スナップショット、またはバックアッププロセスには及びません。
アプリケーションがサポートする整合性確保の方法でデータベースをエクスポートまたはスナップショット化し、その復旧用成果物を同期またはバックアップします。アプリケーションがその構成を明示的にサポートしていない限り、稼働中のデータベースディレクトリは通常の双方向同期から除外してください。
適切な方法で移行可能な設定と秘密情報を保護する
設定ファイル、Composeマニフェスト、テンプレート、選択したアプリケーション設定は、隠しファイルであっても復旧に役立つ場合があります。秘密情報については別途判断が必要です。広く読み取り可能なクラウド同期先は、APIキー、SSH関連データ、セッショントークン、環境ファイルの保存場所として適切でない可能性があります。
除外パターンでは正確なパスを使用するというTrueNASコミュニティの議論は、除外構文をシェルのグロブの習慣から推測するのではなく、同期エンジンが生成する正確な相対パスに対してテストすべき理由を示しています。
また、一般的なクラウドサービスでは、POSIXの所有権、ACL、拡張属性、ハードリンク、すべてのタイムスタンプが保持されない場合があることにも注意してください。設定の内容を保護するとともに、復元に必要な権限やIDマッピングを別途文書化します。
フィルターの変更を段階的に適用し、両方の一覧を比較する
除外設定は、小規模な非本番ツリーでテストするか、ツールが対応している場合はドライランまたは一覧表示モードを使用してください。まず古いルールセットをエクスポートし、削除や双方向の反映を有効にする前に、含まれる相対パスと除外される相対パスを比較します。
新しい除外設定ごとに、パターン、理由、担当アプリケーション、内容が再生成可能かどうか、再生成できない場合にどのバックアップが保護しているかを記録します。これにより、将来リモート側のファイル数に差異が生じても、インシデントではなく、説明可能なポリシーの結果として扱えます。
導入後は、移行可能な設定ファイル1つ、想定した安全な経路による秘密情報1つ、別のバックアップから復元したアプリケーションデータベース1つをテストします。クラウド同期の除外設定は、サービスの再構築に必要なものを削除せずに変更頻度を下げられた場合にのみ最適化されたと言えます。
サポートとヒント
もっと読む

Dockerの再起動ポリシーをデータベース、ワーカー、Webアプリに適用する方法
再起動ポリシーをサービスのライフサイクルと終了時の動作に合わせます。ヘルスチェックおよび準備完了チェックと組み合わせ、依存関係の障害を隠すために再起動ループを使用しないでください。

複数のNAS共有間でコンテナのユーザーIDを設定する方法
各コンテナの UID/GID を NAS の共有フォルダーに割り当て、必要に応じて共有グループや ACL を使用し、PUID/PGID はイメージ固有の設定であって、Docker 全体に共通する設定ではないと考えてください。

オプションのホームサーバーサービス用にDocker Composeプロファイルを設定する方法
必須サービスはプロファイルなしで残し、オプションのツールにはプロファイルを使用します。プロファイルを有効にすればスタック全体が起動すると決めつけず、対象と依存関係を直接テストしてください。

