Time Machineバックアップがtmutilを介して100%CPUで動かなくなる


0

さて、私は最近、Time Machineのバックアップをに切り替えてみることにしました。 tmutil 実行時に正確に制御できるようにするために、前後に追加の処理を実行することもできます。

とにかく、起動エージェントを設定して1時間に1回次のコマンドを実行する簡単なテストから始めることにしました。

tmutil --block

私は使っています --block バックアップが完了するまでジョブが目に見えてアクティブなままであることを確認するためのオプション、および後でコマンドを実行する場合に必要になるためです。私が抱えている問題は、バックアップが最後にFinishingステージに入ると、それが頻繁に動けなくなることです。 backupd CPU使用率を100%まで上昇させる。

Time Machineメニューから「今すぐバックアップ」を選択してバックアップを停止して実行すると、通常のTime Machineの自動バックアップに戻ることができます。

使うときだけ tmutil --block これが起こるように思われるという理由で、何かアイデアはありますか?


「backupdがCPU使用率を100%まで上昇させることで頻繁に動けなくなります...」と言っています。それ自体は悪いことではありません。実際にFinishingステージを終了させたことがあるかどうかは、あなたが書いたものからわかりません。それが動けなくなっていることをどのように知っていますか?あなたはあきらめて仕事をやめる前に、どれだけの時間、あなたは時計の時間内に待っていましたか?プロセスが した 過去に適切に終了しました、どれくらいの時間がかかりましたか?可能であれば、これらのコマンドを使用して空のHDに新しいバックアップを試してください。何が起こるか見てください。
IconDaemon

@IconDaemonは回答してくれてありがとう、しかし問題は非常に長い期間(1時間以上)の間最終段階が100%のCPU使用率に固執していたということです。私は実際に自分自身で問題に答えました、それは私がどういうわけか残り物を持っていたようです .inprogress Time Machineがそれを削除しようとして動けなくなった。何らかの理由で tmutil 問題はなかったので、問題を解決することができました。なぜそれが最初に発生したのかわからないのです。
Haravikk

回答:


1

私はこれをすぐに投稿したかもしれないと感じました。 Time Machineの通常のバックアップでも同じことができます。

しかし、私が発見した原因は、どういうわけか私が .inprogress 最新のバックアップよりも古いバックアップ。どうやってそこに着いたのかわかりませんが、 sudo tmutil delete <path to .inprogress file> 問題を解決しました。

どのようにして残りの.inprogressファイルが作成されたのか、または作成したときに問題が発生し始めたのか、または実行されなかったのかはまだわかりません。自動バックアップには影響しません…

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.