本文へ移動

バックアップ・復元・データ消去

システム設定 → メンテナンス では、fn-knock のアプリレベルの設定を自動または手動でバックアップし、インポートしたり、現在のインスタンスを消去したりできます。.knock アーカイブは移行や設定の切り戻しに適していますが、機器全体、コンテナボリューム、アップストリームサービスのデータをバックアップするものではありません。

バックアップに含まれるもの

エクスポートでは、fn-knock のアプリ用名前空間から復元可能な設定と認証情報を収集します。たとえば、次の内容が含まれます。

  • 認証アカウント、TOTP、パスキー、外部ログインの設定。
  • サブドメイン、パス、ゲートウェイ、WAF、セッションポリシーなどのアプリ設定。
  • 証明書と秘密鍵、DDNS、通知、トンネル接続の設定。
  • その他、fn-knock が永続化し、新しいインスタンスへ再適用できるオブジェクト。

実行ログ、イベント、セッション、一時アクセス許可、ログインのバックオフ状態、ロック、トラフィック統計、WAF 統計、トンネルの実行状態、DDNS が最後に取得したアドレス、その他の短期的な実行データは除外されます。ダウンロードした FRP / Cloudflared / acme.sh のファイル、ホストのファイアウォール状態、外部 DNS レコード、アップストリームアプリのデータも、アプリバックアップには含まれません。

このため、環境全体を移行するときは通常、次の 2 段階のバックアップが必要です。

  1. メンテナンス画面からエクスポートした .knock。アプリ設定の復元に使用します。
  2. プラットフォームのデータディレクトリ、Docker ボリューム、またはシステムスナップショット。SQLite、ダウンロード済みリソース、プラットフォームの実行データを保持するために使用します。

セキュリティ上の注意

.knock はパスワード付きの ZIP 互換形式を使用します。この固定アーカイブパスワードは、業界で一般的な低コストのアプリケーションパッケージ方式です。fn-knock のバックアップ形式をアプリが識別しやすくし、誤操作や安易な内容変更へのハードルを上げながら、ZIP 圧縮でファイルサイズを削減できます。ユーザーのログインパスワードを保存または暗号化する仕組みではなく、ユーザーパスワードが平文でアーカイブへ書き込まれることも意味しません。固定アーカイブパスワードの採用自体は、「パスワードの平文保存」によるセキュリティ事故ではありません。

アーカイブパスワードはアプリとともに配布されるため、暗号化や機密保持を目的としていません。アーカイブには証明書の秘密鍵、TOTP seed、アカウント認証情報のハッシュ、OIDC / DDNS / 通知 / FRP など、直接利用可能な機密設定が含まれる可能性があります。そのため、ファイル自体は機密設定のバックアップとして扱ってください。

  • 暗号化されたディスク、信頼できるパスワード保管庫、または管理されたオフラインメディアだけに保存する。
  • クラウドストレージ、メール、チャットツールで転送する前に、別途強力な暗号化を施す。
  • 公開 Issue、グループチャット、公開共有ディレクトリ、診断用の添付ファイルへアップロードしない。
  • 古いコピーを定期的に削除し、バックアップの読み取り権限を実際の保守担当者だけに制限する。

自動バックアップ

システム設定 → メンテナンス → 自動バックアップ では、サーバーのデータディレクトリ内にある backups/automatic.knock を定期的に保存できます。デフォルトは無効、間隔は 24 時間、保持期間は 7 日です。間隔は 18760 時間、保持期間は 13650 日に設定できます。

初めて有効にするとバックアップがすぐに 1 件作成され、その後は設定した間隔で実行されます。画面には実際のディレクトリ、直近の成功日時、次回予定、直近のエラーが表示されます。失敗時は前倒しで再試行され、遅くとも約 1 時間以内に再実行されます。クリーンアップが削除するのは、自動バックアップディレクトリ内で保持期間を過ぎた .knock アーカイブだけで、無関係なファイルは古いバックアップとして削除されません。

自動バックアップと手動エクスポートでは、内容、互換性、セキュリティ上の境界は同じです。自動バックアップは現在のサーバーのデータディスクまたはコンテナボリュームに保存されるため、ディスク障害、ボリューム消失、ホスト全体の障害には対応できません。重要なコピーは定期的に別の機器または管理されたオフサイトストレージへ移してください。

復元時は 自動バックアップから選択 を使うと、ブラウザー端末へ先にダウンロードせず、サーバー側の自動バックアップディレクトリから直接選択できます。復元では現在の自動バックアップスケジュールが保持されるため、古いアーカイブで意図せず上書きされません。「すべてのデータを消去」後も既存の自動バックアップファイルはサーバーディレクトリに残りますが、スケジュール設定は無効へリセットされます。再度有効にする前に、古いファイルを保持する必要があるか確認してください。

バックアップのエクスポート

システム設定 → メンテナンス → バックアップのエクスポート を開きます。

  • 画面で共有ディレクトリを利用できる場合は、fn-knock / backup へ書き込むか、現在ブラウザーを開いている端末へダウンロードできます。
  • その他のデプロイでは、現在の端末へ直接ダウンロードします。
  • ファイル名は fn-knock-backup- で始まり、.knock で終わり、エクスポート日時が含まれます。

共有ディレクトリの選択肢は通常、fnOS ネイティブ FPK、または対応する共有ルートを明示的にマウントした環境でだけ表示されます。Docker と OpenWrt では表示されません。共有ディレクトリが自動的に安全になるわけではないため、アクセス権限も確認してください。

次のタイミングでのエクスポートを推奨します。

  • 認証、ルーティング、証明書の初期設定が完了した後。
  • 動作モード、ルートドメイン、認証方式、WAF を変更する前。
  • アプリの更新、移行、再インストール、データ消去を行う前。
  • 認証情報、証明書、DDNS、トンネル設定に重要な変更を加えた後。

エクスポートの完了だけでは、バックアップが利用可能だとは限りません。少なくともファイルが空でなく、拡張子が正しいことを確認し、分離したインスタンスまたは切り戻し可能なインスタンスで定期的にインポートを試してください。

インポート前の確認

インポートはマージではなく、現在の fn-knock アプリ用名前空間を置き換える操作です。開始前に、次の準備を行います。

  1. 現在のインスタンスから、切り戻し用バックアップをもう 1 つエクスポートします。
  2. LAN、デスクトップの入口、またはシステムコンソールから管理画面へ再び入れることを確認します。
  3. アーカイブの提供元が信頼でき、信頼できない端末で展開または変更されていないことを確認します。
  4. 現在のバージョン、動作モード、認証用 Host、ゲートウェイポート、重要なサービスマッピングを 1 つ記録します。
  5. 別のプラットフォームへ移行する場合は、ファイアウォール、ポート公開、共有ディレクトリ、外部 DNS の状態も記録します。

現在サーバーが受け付けるアーカイブは、次の条件を満たす必要があります。

  • 拡張子が .knock である。
  • サイズが 128 MiB 以下である。
  • 現在対応しているバックアップ Schema を使用している。現在は Schema 1
  • アーカイブ内のアプリバージョンが、現在のコードで定義された最低互換バージョン(現在は 1.4.0)以上である。
  • アーカイブ内のアプリバージョンが、実行中の fn-knock バージョン以下である。

このため、新しいバージョンでエクスポートしたバックアップを古いバージョンへ直接復元することはできません。先に復元先を同じかそれ以上のバージョンへ更新してから、インポートしてください。具体的な対応範囲は、失敗メッセージに表示されるバージョン範囲に従います。

復元の実行

  1. メンテナンス画面でローカルの .knock ファイル、またはサーバー側の自動バックアップディレクトリにあるファイルを選びます。共有ディレクトリに対応している場合は、fn-knock / backup からも選択できます。
  2. ファイル名、サイズ、提供元を確認し、インポートを開始します。
  3. 上書きに関する警告を読み、確定します。
  4. インポート結果を待ちます。成功すると画面が再読み込みされます。

サーバーは既存の fn_knock: データを消去し、アーカイブ内の復元対象として許可された項目を書き込みます。その後、次の項目を順に同期します。

  • 現在の動作モードとゲートウェイルート。
  • 直接接続モードの IP 許可リスト(該当する場合)。
  • ゲートウェイログ、WAF、SSL のデプロイ。
  • 古い認証ログの整理と、システムリソース監視の状態。

インポート結果の「警告」は、設定項目のインポートは完了したものの、1 つ以上の実行状態の同期に失敗したことを示します。インスタンス全体がインポート前の状態へ自動的にロールバックされることはありません。警告の内容を保存し、管理入口を利用できる状態に保ちながら、次の節に沿って項目ごとに対処してください。

復元後の確認

管理画面から公開側の経路へ向かう順に確認します。

  1. 管理画面へ再び入れるか、認証アカウント、TOTP、パスキー、外部ログインが想定どおりかを確認します。
  2. 動作モード、ルートドメイン、認証用 Host、マッピング数、重要な Target が正しいことを確認します。
  3. ゲートウェイ、WAF、証明書、リクエストログが正常か確認します。警告がある場合は、対応する同期ステップから確認してください。
  4. FRP / Cloudflared のリソースがインストールされ、再び実行されていることを確認します。
  5. DDNS、通知プロバイダー、外部ログインの認証情報を正常にテストできるか確認します。
  6. モバイル回線から認証用 Host と、少なくとも 1 つの保護対象サービス用 Host へアクセスします。
  7. リクエストログの実クライアント IP、ルート、アップストリームの状態が正しいことを確認します。
  8. 別のプラットフォームへ移行した場合は、ポート公開、ホストのファイアウォール、スマート接続、システムサービスを再設定します。

復元した設定が、以前の環境のループバックアドレス、LAN 内 IP、ファイルパス、ドメインを参照している場合があります。設定項目が存在していても、それらの外部依存先が新しいプラットフォームにも存在するとは限りません。

よくある失敗

メッセージまたは症状対処方法
ファイル拡張子が正しくない元の .knock を選びます。通常の ZIP や JSON の拡張子だけを変更しないでください
Schema またはバージョンに非対応復元先を表示された範囲内のバージョンへ更新します。アーカイブのバージョン項目を手作業で書き換えないでください
アーカイブが大きすぎるファイルが破損または置き換えられていないか確認します。1 ファイルの上限は 128 MiB です
アーカイブの読み取りに失敗ファイルの完全性、空きディスク容量、unzip が利用可能かを確認します。一部の Linux / OpenWrt 環境では、システムのパッケージマネージャーから unzip のインストールを試みます
共有ディレクトリを利用できないプラットフォームが共有ルートを提供しているか、ディレクトリが引き続きマウントされ、プロセスから読み書きできるかを確認します。ローカルへのダウンロードとアップロードに切り替えることもできます
インポートは成功したが警告があるインポートを繰り返さないでください。まず警告に対応する動作モード、WAF、SSL、ゲートウェイの同期を確認し、必要に応じて関連設定を手動で保存します
画面の再読み込み後、公開側からログインできない残しておいた LAN またはプラットフォームの入口から入り、認証用 Host、DNS、証明書、外部ポートを確認してから、インポート前のバックアップへ戻すか判断します

すべてのデータを消去

システム設定 → メンテナンス → クリーンアップ → すべてのデータを消去 を実行すると、ゲートウェイがリセットされ、サーバーのストレージにある設定、アカウント、セッション、ログ、その他のアプリデータが削除されます。その後、現在のブラウザーのローカルストレージも消去され、画面が再読み込みされます。

操作するには、画面に表示される確認フレーズを入力する必要があります。日本語画面では現在、すべてのデータを消去 です。この操作は取り消せず、エクスポート済みファイルの内容が自動的に復元されることもありません。バックアップを検証し、管理入口とデプロイ先のデータディレクトリに問題がないことを確認したうえで、インスタンスを再初期化する意思が明確な場合にだけ実行してください。

QQ コミュニティ:1081609274