web-dev-qa-db-ja.com

デバイスが特定のフォルダにマウントされていることを検出していますか?

バックアップスキームの刷新の一環として、回転式の外付けハードドライブを追加し、一方がバックアップデータを受信して​​いる間、一方を常に安全にオフサイトに保ちます。当然、バックアップが実際に実行されるようにするために、バックアップはスクリプト化され、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スクリプトも恐れません)。

5
Kromey

Cronでそのようなバックアップスクリプトを実行できます

fgrep -q /mnt/backup /proc/mounts && backup.sh

ただし、失敗した試行をログに記録するには、スクリプトにテストを追加することをお勧めします

3
forcefsck

/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にジョブの実行方法を指示することです。お気づきのように、デバイス名は常に変化するため、信頼することはできません。しかし、実際のデバイスはそれ自体で認識できます。ハードディスクの場合、パーティションの名前は、blkidvol_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に関連付けることです。スクリプト(通常のユーザーモードでも)は、xxxxxxxmount -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に従ってマウントできるデバイスであっても、スーパーユーザーのみが使用できるようです。繰り返しますが、なぜだろうか。

0
babou