Kodama's home / tips.

ディレクトリの複製/移動/バックアップ

ディレクトリの移動

ディレクトリを対象とする mv は, 同一ファイルシステム上でしかできません. 移動は, 複製しておいて,元を消せば良いので 複製に注目しましょう.

ディレクトリの複製

普通 tar でしょう？ 

(cd /source/directory && tar cf - . ) | (cd /dest/directory && tar xvfp -)
(LDP(翻訳JF) の Tips-HOWTO から)
(GNU tar なら --directory をつかう？)

cp -a も良いですよ. link や /dev/ も OK です. 空ディレクトリの複製ができないとか, ちょっとした問題はあるけど. 

cp -a /source/directory/* /dest/directory

バックアップ

HDD が大容量になってきて, バックアップに悩んでいると思う. ディレクトリやディスクのバックアップ, どうしてますか？

通常の運用系のディスクと同等かそれよりも大きいディスクを用意しておいて rsync を使うのが一番楽ができるようです. 数百G程度のファイルサーバなら, 主サーバには Raid 0+1 のディスクを用います(速度の要求が高く無いなら Raid 5 の方が安価). バックアップサーバには 同程度以上の Raid 5 のディスクを用います. 他の運用に影響の無い高速の回線でつないでおいて 定期的に rsync するように設定するとできあがりです. 緊急時には, バックアップサーバをメインのサーバとすり替えて動作させることもできます. ディスクはホットスワップ(動作させたまま機材の交換が可能), ホットスペア(故障時に自動的に予備の部品に切替え) 対応にします.

数G〜数十Gの容量なら, ディスクを余分に用意して 複数台でのロ−テ−ションをスクリプトにしておいて cp -a でバックアップを取るようにしても良い. 下のような感じでやれば, "最低限の" 対策はとれる. 

BACKUDEV="/dev/hda1"   # 複数台で ロ−テ−ションしたい
mount $BACKUPDEV /backup
rm -r /backup/home  # 前回のゴミを掃除
cp -a /home /backup
umount /backup
cron で実行する場合, バックアップは夜中から明け方にかけて行うだろうから, スクリプト内の各段階でエラ−をチェックして, 操作に失敗した場合, mail で報告を出させるとか, ロ−テ−ション計画を再編成するとか, いくつか工夫は必要.

ディスクを抜いて別に保管したい場合でも, サ−バ−の場合止めるわけには行かない. ラトック社から, デスクトップ用に PCMCIAドライブ が出ているのでこれを使うと良い. 必要に応じて SCSI ドライブを差すわけ.

SCSI ディスクは高価だけど, IDE のディスクを SCSI ディスクとして使えるアダプタ−があったと思う. 記憶が朧ろ〜

うまく組合せると, 普通のディスクが交換可能なメディアみたいに使えるはず. 

Kodama's home / tips.