Time Machine によるバックアップ
Time Machine のバックアップルールは、
1時間ごとのバックアップを 24時間ごと繰り返し、
1日ごとのバックアップを1ヶ月繰り返し、
1週間ごとのバックアップを毎月繰り返す。
ちょっと贅沢な HDD の使い方ではあるが、一般ユーザとしては、ひと月以上前の状態に戻したい、などという特殊なリカバリは必要なく、とりあえず問題が起こったら、問題が発生していなかった直近の状態に戻せればいい訳で、その目的からして理にかなったスケジューリングだと思う。
ところで、DAW で Mac の内蔵 HDD へのレコーディング作業をしているとき、Time Machine は必ず OFF にした方が良い。
DAW アプリケーションのプロセスが HDD の I/O をコントロールしている裏で、Time Machine プロセスも同じ領域を同時に Read したらどうなるか。
当然のことながら、HDD のシークが二ついっぺんに実行されてしまうために、双方の Read に多少の遅延が発生する。
Read 遅延のスパンが延びれば延びるほど、アプリケーション側では HDD への書き込み用バッファの保持に負荷がかかり、エラーの原因となる。
作業中のリアルタイムバックアップ、という考え方は、例えば HDD が RAID 化されていたりすれば実現可能だが、Time Capsule などの外付け HDD に対して上記のようなスケジューリングによるバックアップを行う場合、HDD への書き込み頻度が高くなるようなアプリケーションを実行する際は注意した方が良い。
- 過去 24 時間の 1 時間ごとのバックアップ
- 過去 1 ヶ月の 1 日ごとのバックアップ
- 過去のすべての月の 1 週間ごとのバックアップ
1時間ごとのバックアップを 24時間ごと繰り返し、
1日ごとのバックアップを1ヶ月繰り返し、
1週間ごとのバックアップを毎月繰り返す。
ちょっと贅沢な HDD の使い方ではあるが、一般ユーザとしては、ひと月以上前の状態に戻したい、などという特殊なリカバリは必要なく、とりあえず問題が起こったら、問題が発生していなかった直近の状態に戻せればいい訳で、その目的からして理にかなったスケジューリングだと思う。
ところで、DAW で Mac の内蔵 HDD へのレコーディング作業をしているとき、Time Machine は必ず OFF にした方が良い。
DAW アプリケーションのプロセスが HDD の I/O をコントロールしている裏で、Time Machine プロセスも同じ領域を同時に Read したらどうなるか。
当然のことながら、HDD のシークが二ついっぺんに実行されてしまうために、双方の Read に多少の遅延が発生する。
Read 遅延のスパンが延びれば延びるほど、アプリケーション側では HDD への書き込み用バッファの保持に負荷がかかり、エラーの原因となる。
作業中のリアルタイムバックアップ、という考え方は、例えば HDD が RAID 化されていたりすれば実現可能だが、Time Capsule などの外付け HDD に対して上記のようなスケジューリングによるバックアップを行う場合、HDD への書き込み頻度が高くなるようなアプリケーションを実行する際は注意した方が良い。
コメント
コメントを投稿