移行後、バックアップが4倍の時間がかかる

画像を手動で復元しました。古いホスティングからコピーしました。動作はしますが、バックアップに問題があり、同じ設定でも容量が4倍になってしまいました。

不要なファイルをすべて削除する方法はありますか?

おそらくレチナ画像のサイズ設定によるもので、ユーザーのデバイスの解像度に応じて画像の複数のコピーが必要になるためです。

元のアセットのみを対象としたバックアップオプションを導入することは可能でしょうか。復元時に多くの再処理が必要になることは理解していますが、運用担当の立場から言えば、ローカルディスク容量の節約やシステム間の転送において非常に役立つと思います。

わかりましたが、なぜ同じもののコピーが移行後にちょうど4倍のサイズになってしまうのでしょうか?

結局のところ、ファイルもコンテンツも全く同じままです。それがどこから来るのかがわかりません。

これは主にキャッシュの問題です。そうでなければ、画像をリアルタイムで小さなサイズに再レンダリングする必要があり、それは非常に計算集約的になります。

@stephen さん、おっしゃる通り、バックアップはこの部分はスキップできるかもしれません。@sam さんも以前にこの点に触れたことがありますよね?唯一の欠点は、バックアップの復元時に非常に CPU 負荷が高くなることです。なぜなら、バックアップからすべての解像度を再レンダリングする必要があるからです。しかし、私の考えでは、それは深刻な欠点ではありません。急いでいる場合や、CPU 性能が低いサーバーを使っている場合を除いては、ですが。

全員に当てはまるわけではないですが、バックアップ用に4倍のディスク容量を割り当てる必要があるよりも、アセットを再生成するための短期的なCPU負荷を受け入れるオプションの方が好ましいです。

どうやってやるんですか?

それがバックアップの仕組みです。デフォルトでは、サムネイルはバックアップに含まれません。その設定は少なくとも1年前に変更されました。

include_thumbnails_in_backups サイト設定でその動作を構成できます。

バックアップに生成されたサムネイルを含めます。これを無効にするとバックアップが小さくなりますが、復元後にすべての投稿の再レンダリングが必要です。

@eextra バックアップのサイズがこれほど大きくなっている理由を特定するために、古いバックアップと新しいバックアップの内容に対してファイルベースの差分を作成することをお勧めします。

私の誤解でした——@gerhard さん、ご説明ありがとうございます :clinking_beer_mugs: .. その方がデフォルトとして適切だと思います。