WordPressバックアップの保持について
ローカルバックアップの保持数とリモートの有効期限を比較し、差分バックアップの依存関係を維持して、使用可能なWordPressのコピーを確認します。
最終確認日
スクリーンショットは英語版の画面です。
WordPressはローカルバックアップを件数で、リモートバックアップを有効期限の時刻で保持します。これらは独立したポリシーです。ローカルの整理はdosyaのコピーの期限切れを証明せず、リモートの期限切れはプラグインのローカル保持数を変更しません。
手順
- dosya Backup → Scheduleを開き、Keep on this serverを確認してください。ローカルで設定できる件数は1〜30で、新規インストールの標準は3です。
- dosyaタブを開き、接続サイトのRetentionを確認してください。現在のリリースでは、アカウントプランにより高い保持上限があっても、新しい接続は7日で初期化されます。
- Backupsに戻り、各作成時刻を2つのポリシーと比較します。リモートの完了時に、サイトに保存された保持日数に基づいて
expires_atが設定されます。 - ローカルの整理が行われる前にバックアップを成功させてください。ローカルストアは成功後に整理し、保持される差分バックアップが参照する古いバックアップは残します。
- 古いフルバックアップは、単純な保持数を超える日付だからといって削除しないでください。新しいバックアップが1件以上依存している場合、UIは削除を拒否し、依存する件数を示します。
- 後の行がフルバックアップの場合は、連鎖が自動で開始し直されたものとして扱ってください。使用可能な以前のリモートマニフェストがない、基礎となる連鎖が30日以上経過、以前の一覧を取得できない、必要なローカルボリュームがない、または参照上限を超えた場合にプラグインはフルを選択します。wp-adminにフルバックアップを強制する操作はありません。
ローカル設定は成功した実行の後にのみ古い完了済みバックアップを削除します。実装の確認ではexpires_atへのAPIによる設定を確認しましたが、その瞬間に物理的な削除が行われることを保証するローカルの本番クリーンアップ仕様は見つかっていません。
期待される結果
ローカルの保持数に従うコピーと、リモートの有効期限が付いたコピーを区別できます。必要な差分バックアップの基礎は参照されている間ローカルに残り、リモートのレコードには物理削除の正確な時刻を保証せずに有効期限が表示されます。
関連ガイド
この記事は役に立ちましたか？
評価の結果を読み込んでいます…
投票すると、回答を変更できるように、必要な投票用Cookieが最長180日間保存されます。
質問と回答
このガイドの手順について質問できます。質問は確認後に公開されます。
公開の質問には、アカウントの詳細、認証情報、非公開ファイルを含めないでください。これらについては 非公開サポート をご利用ください。
質問を読み込んでいます…
dosyaアカウントにサインインすると、質問を投稿できます。