バックアップスキームの刷新の一環として、回転式の外付けハードドライブを追加し、一方がバックアップデータを受信している間、一方を常に安全にオフサイトに保ちます。当然、バックアップが実際に実行されるようにするために、バックアップはスクリプト化され、cronされます。
私の計画は、ハードドライブを手動で接続してマウントし、マウントを解除するまで(再び手動で)そのままにして、取り出して次のハードドライブを持ち込み、(手動で)マウントすることです。両方のドライブは、例えばにマウントされます。/mnt/backup。
ここで、質問があります。ハードドライブを接続またはマウントするのを忘れた場合に、バックアップスクリプトを実行したくないのです。したがって、スクリプトの実行を許可する前に、/ mnt/backupにマウントされているデバイスがあるかどうかを検出できる必要があります。私の最初の考えは、例えばという名前のファイルを置くことです。 (マウントされていない)/ mnt/backupディレクトリにある 'NO_DRIVE_MOUNTED'を確認し、バックアップルーチンを実行する前にnotが存在することを確認しますが、それはハックのように感じます。 (同様に、たとえば「BACKUP_DEVICE_READY」という名前のファイルを各外付けハードドライブに配置し、そのファイルdoesが存在することを確認するのとは逆に、ハックのように感じます。)
デバイスが特定のディレクトリにマウントされているかどうかを検出するためのより良い方法はありますか? Linuxでドライブを接続すると、次に使用可能な/ dev/sdXに割り当てられるだけなので、デバイス自体をチェックするのは避けたいと思います。バックアップドライブはいつか/ dev/sdfになる可能性があります。次回バックアップドライブを接続するときに別のドライブを接続すると、/ dev/sdgになります。つまり、/ dev/sdfのテストは失敗します。また、ドライブをより簡単かつ透過的に交換/アップグレードできるように、デバイス固有の識別(UUIDなどによる)を避けたいと思います。
これはUbuntu10.10(または、とにかくサーバー全体を再構築している途中なので、足を十分長くドラッグした場合は11.04)になります。理想的には、プレフィックスを付けることができる簡単な1行のテストが必要です。 crontabで直接バックアップコマンドを実行します(ただし、必要な場合は、Bashスクリプトも恐れません)。
Cronでそのようなバックアップスクリプトを実行できます
fgrep -q /mnt/backup /proc/mounts && backup.sh
ただし、失敗した試行をログに記録するには、スクリプトにテストを追加することをお勧めします
/mnt/backup
がマウントポイントであるかどうかを確認する2つの方法があります。 /proc/mounts
メソッドはLinuxに固有であり、df
メソッドはすべてのUNIXシステムに移植可能です。それ以外に、どちらかを好む主な理由はありません。マウントポイントに空白が含まれている場合、両方とも失敗する可能性があります(ただし、そうしないでください)。
case $(df -P /var) in *" /var") echo mounted;; esac
if fgrep -q " /tmp " </proc/mounts; then echo mounted; fi
デバイスのシリアル番号、ファイルシステムのUUID、ファイルシステムのラベルなどの基準に基づいて、特定のデバイス名を特定のリムーバブルドライブに割り当てることができることに注意してください(後者は信頼できる指標になる可能性があります)。必要なのは、udev構成の1行だけです。ただし、適切なマウントポイントへのマウントを容易にすることは良い考えですが、デバイスの存在に依存することは適切ではありません。デバイスは存在する可能性がありますが、マウントされていない可能性があるため、スクリプトがマウントされたデバイスに依存している場合は、マウントを確認する必要がありますポイント。
あなたがやりたいことを達成するための別の(より良い?、より安全な?)方法があります。バックアップドライブがマウントされているかどうかを確認する代わりに、プラグを差し込んだままにして、実際に使用しないときはマウントを解除してください。
これはおそらくディスクにとってより良いものであり(一部はただ休むだけです)、誤ってディスクにアクセスすることを回避します。 cronジョブは、開始時にmount
、終了時にumount
できます。これは、mount /mnt/backup
のエントリに必要な内容を記述していれば、コマンドumount /mnt/backup
および/etc/fstab
を使用して通常のユーザーとして実行できます。マウントが通常のユーザーとして行われる場合、エントリにはオプションusers
を含める必要があります。これで、ディスクが実際に接続されているかどうかを検出するだけで済みます。 mount
コマンドは、プラグが抜かれたディスクをマウントしようとしてエラー32で失敗することにより、そのことを通知します(このエラーには他の原因もあります)。
最後のポイントは、/ etc/fstabにジョブの実行方法を指示することです。お気づきのように、デバイス名は常に変化するため、信頼することはできません。しかし、実際のデバイスはそれ自体で認識できます。ハードディスクの場合、パーティションの名前は、blkid
やvol_id
などの適切なツールで判別できます。コマンドblkid
は、/sbin/blkid
を呼び出す通常のユーザーに対して機能します。 (ところで、これはDVDでも機能します)。
たとえば、現在デバイス/dev/sdc
にある2つのパーティションを持つディスクがあります。スーパーユーザーとして呼び出すことにより、最初のパーティションの「UUID」を取得します。
$ /sbin/blkid /dev/sdc1
/dev/sdc1: UUID="7aeb2d15-9a1b-410a-b5ed-5437e68cb528" SEC_TYPE="ext2" TYPE="ext3"
次に、/etc/fstab
に行を追加します
UUID="7aeb2d15-9a1b-410a-b5ed-5437e68cb528" /mnt/backup ext3 users,noauto,rw,relatime,data=ordered
/etc/fstab
は、mount /mnt/backup
に適切な情報を提供して、適切なパーティション(使用可能な場合)を/mnt/backup
にマウントします。同じことがumount
にも当てはまります。
残念ながら、これはバックアップDVDが1枚の場合にのみ機能します。その理由は、mount /mnt/backup
コマンドは、マウントポイントとして/etc/fstab
を持つ/mnt/backup
の最初のエントリを使用するためです。プラグインしたディスクと一致しない場合、同じマウントポイントの別のディスクでジョブを実行する可能性のあるエントリをさらに探すことなく失敗します(なぜだろうか)。
解決策は、すべてのバックアップディスクを/mnt/backup
のマウントポイントとして/etc/fstab
に関連付けることです。スクリプト(通常のユーザーモードでも)は、xxxxxxx
がmount -U 'xxxxxxx'
でディスク(パーティション)を識別するために使用されるそのディスク(パーティション)のUIDである場合、/etc/fstab
を使用して各バックアップディスクパーティションをマウントしようとします。バックアップディスクの1つが接続されている場合、スクリプトは最終的に成功します。
これにより、バックアップディスクと間違えられたディスクの偶発的な破壊も防止されることに注意してください。スクリプトに認識されていないディスクを接続すると、ディスクの/etc/fstab
にエントリが含まれていても、スクリプトはそのディスクをマウントできません。
チェックするもう1つの(さらに単純な)可能性(私はそれを使用したことはありません)は、コマンドmount -a -O my_option
を使用して、/etc/fstab
エントリにオプション'my_option'
が含まれるすべてのディスクをマウントすることです。そしてもちろん、/etc/fstab
のバックアップディスクの各エントリにそのオプションを追加する必要があります。これに伴うリスクは、2つのバックアップディスクが接続されている場合、それらが/mnt/backup
で互いに重なり合ってマウントされる可能性があることです。一番上の2番目のものだけが見えるので、これは問題ではないはずです。しかし、最後に両方が確実に取り外されるように注意する必要があるかどうかはわかりません。いくつかの実験はおそらく順調です。
ただし、mount -a -O my_option
は、通常のユーザーが/etc/fstab
に従ってマウントできるデバイスであっても、スーパーユーザーのみが使用できるようです。繰り返しますが、なぜだろうか。