ZoneMinderは自宅サーバとしてHPの「DL360 G7」上で使っていますが、300GBのSAS 4台でRAID1+0（10）を構成しているため、実質580GBほどしか使えません。
最初のうちは良かったのですが、カメラを増設して8台になり、全て1920×1080で動画も生のまま保存するようにしたら、12時間ほどしか記録できなくなったため、外付けHDDに保存することにしました。
後述しますが、ここまで極端に記録期間が短くなったのは、データベースに存在しないイベント画像・動画の残骸があったためで、掃除の方法も末尾あたりで紹介しています。
増設したのは以下の中国メーカーのもので、15000円のお値打ち価格でHDDを4台収容、個別のHDDとして使うSingleモードのほか、RAID0、RAID1、RAID3、RAID5、RAID10、SPAN(JBOD)に対応しています。
作りはかなりチープで、前面扉はプッシュオープンでロックなし、HDDトレイへはネジ止めしますがネジが浅すぎて固定が心配だったり、トレイのロックが無いので地震のときに飛び出てきそうで不安になります。
しかし、USB3-SATAブリッジには「JMicron」の「JMS567」が、RAIDコントローラも同社の「JMB394」と一般的なものが使われており、しばらく使ってみた感じでは安定感があって良いんじゃないかと思います。
ケース自体がアルミ製のため放熱も良さそうなのも良かったですね。
HDDは余ってた「Western Digital」の「WD1003FBYX」を4枚でRAID0にしました。
ベンチマークは以下のような感じで、HDD単体の2倍近い速度が出ています。
このHDDは既に6万時間を余裕で超えて7万時間に入りそうなくらいの長期間を常時稼働で使っていますが、エンタープライズモデルのためか非常に頑丈で、これまでもノートラブルな頼もしいやつです。
サーバー向けのSASやSCSIなどは非常に高価ですが頑丈で、交換した記憶が無いくらいたまにしか故障しませんが、それに近い感じの安心感があります。
HDDの準備
とりあえず接続して確認
認識しているか確認します。
USB-SATAブリッジの「JMS567」が追加されたのが確認できました。
[root@sakue ~]# lsusb Bus 001 Device 002: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
/var/log/messages でも確認します。
May 14 15:49:09 sakue kernel: usb 1-8: new high-speed USB device number 4 using ehci-pci May 14 15:49:09 sakue kernel: usb 1-8: New USB device found, idVendor=152d, idProduct=0567, bcdDevice= 3.23 May 14 15:49:09 sakue kernel: usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3 May 14 15:49:09 sakue kernel: usb 1-8: Product: USB to ATA/ATAPI Bridge May 14 15:49:09 sakue kernel: usb 1-8: Manufacturer: JMicron May 14 15:49:09 sakue kernel: usb 1-8: SerialNumber: 0123456789ABCDEF May 14 15:49:09 sakue mtp-probe: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-8" May 14 15:49:09 sakue mtp-probe: bus: 1, device: 4 was not an MTP device May 14 15:49:09 sakue kernel: usbcore: registered new interface driver usb-storage May 14 15:49:09 sakue kernel: scsi host3: uas May 14 15:49:09 sakue kernel: usbcore: registered new interface driver uas May 14 15:49:09 sakue kernel: scsi 3:0:0:0: Direct-Access JMicron Generic DISK00 0103 PQ: 0 ANSI: 6 May 14 15:49:09 sakue kernel: sd 3:0:0:0: Attached scsi generic sg3 type 0
「fdisk -l」で確認すると /dev/sdb として認識しています。
先にWindowsで動作確認もしたのでGPTでフォーマットされています。
Disk /dev/sdb: 3999.8 GB, 3999822512128 bytes, 7812153344 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O サイズ (最小 / 推奨): 4096 バイト / 4096 バイト Disk label type: gpt Disk identifier: 17D0A9E0-2A5E-421A-9878-9F5E27D43A05 # Start End Size Type Name 1 34 32767 16M Microsoft reser Microsoft reserved partition パーティション 1 は物理セクタ境界で始まっていません: 2 32768 7812149247 3.7T Microsoft basic Basic data partition
パーティションの削除と作成
コピペするのを忘れてしまったので省略しますが、以下のように引数へ認識したデバイス名を指定すると対話モードでパーティション操作ができます。
fdisk /dev/sdb
ext4でフォーマット
これもデバイス名を指定しますが、パーティションが1つだけの場合は /dev/sdb なら /dev/sdb1 と、1つめのパーティションというのを指定します。
mkfs.ext4 /dev/sdb1
数分かかるので放置しておきます。
マウント
マウントポイントを作成します。
/mnt/ 以下に作成すればよく、名称はお好みでOKです。
mkdir /mnt/yottamaster-raid0
マウントしてみます。
mount /dev/sdb1 /mnt/yottamaster-raid0
「df -h」で確認してみます。
指定した /mnt/yottamaster-raid0 にマウントされ、ディスク容量も正しいのが確認できました。
[root@sakue ~]# df -h ファイルシス サイズ 使用 残り 使用% マウント位置 devtmpfs 36G 0 36G 0% /dev tmpfs 36G 153M 36G 1% /dev/shm tmpfs 36G 250M 36G 1% /run tmpfs 36G 0 36G 0% /sys/fs/cgroup /dev/sda3 554G 376G 179G 68% / /dev/sda1 1014M 327M 688M 33% /boot /dev/sdb1 3.6T 6.8G 3.4T 1% /mnt/yottamaster-raid0 tmpfs 7.1G 0 7.1G 0% /run/user/0
自動マウント
/etc/fstab に記載しておくとサーバのリブート後も自動でマウントしてくれます。
注意が必要なのは複数のドライブが接続されている場合で、/dev/sdb などのデバイス名は認識順で変化してしまうため、再起動のタイミングで指定ドライブが異なるマウントポイントにマウントされる事があります。
これを知らなかったときは忘れた頃にドライブが入れ替わってしまっていて混乱しました。
# 以下のような指定だとデバイス名が起動順により変化するのでNG /dev/sdb1 /mnt/yottamaster-raid0 ext4 defaults 0 0
この場合はデバイス名でなくドライブのUUIDを指定してマウントします。
一覧で確認する場合は以下を実行します。
blkid -o list
こんな感じで「デバイス名」「ファイルシステム」「マウントポイント」「UUID」が確認できます。
[root@sakue~]# blkid -o list device fs_type label mount point UUID ----------------------------------------------------------------------------------------------------------------------------------- /dev/sda3 xfs / 7d99d495-3cd9-498d-8560-2cf9482a98e9 /dev/sda1 xfs /boot 8e134dcf-6fee-42fb-aa0c-ab0d517b8e03 /dev/sda2 swap <swap> f6d07c8a-e0c4-460d-b908-e4e593271ba7 /dev/sdc1 ext4 /mnt/yottamaster-raid0 518c8a29-3139-44e8-8e54-bed09e81c098 /dev/sdb1 ext4 /mnt/logitec-raid1 52375c6d-8185-4f80-8db6-9d70d5d9bed0
個別に確認する場合は以下のようにします。
tune2fs -l [デバイス名] | grep UUID
実行例はこんな感じです。
[root@sakue~]# tune2fs -l /dev/sdc1 | grep UUID Filesystem UUID: 518c8a29-3139-44e8-8e54-bed09e81c098
/etc/fstab で以下のように指定します。
デバイス名での指定と異なるのは先頭付近が「UUID=」で指定している点のみです。
UUID=518c8a29-3139-44e8-8e54-bed09e81c098 /mnt/yottamaster-raid0 ext4 defaults 0 0
追記したら、正しく自動マウントしてくれるか再起動して確認しておきます。
Zoneminderの設定
イベント保存ディレクトリの作成
Zoneminderの設定からストレージを追加しただけでは保存ディレクトリは作成されないため、予め作成しておきます。
書き込み権限があるディレクトリを指定すればいいので、以下の通りに指定する必要はなく、ディレクトリ名などはお好みのものでOKです。
ドライブ直下に「zoneminder」ディレクトリ作成
作成した「zoneminder」ディレクトリ内に「events」ディレクトリを作成します。
書き込み権限をつけておきます。
ストレージの追加
上部メニューから「Options」に入り、左メニューから「Storage」を選択します。
「ADD NEW STORAGE」で追加します。
「Name」は分かりやすい名称を適当に、「Path」に先程作成したイベント保存用ディレクトリを指定します。
それ以外のオプションはデフォルトのままでOKです。
保存ディレクトリの指定
イベントの保存ディレクトリはカメラごとの設定から行います。
このため、複数のストレージがある場合は、カメラごとに別々のHDDへ保存してもOKです。
複数のカメラをいきなり全部変更するより、影響の無さそうなカメラをまず1台だけ設定し、イベントが正しく確認されるか動作確認した方が良いです。
カメラの設定へ入り、左メニューから「Storage」を選択します。
「Storage Area」をクリックすると、先程追加したストレージ名が出てきますので、選択して「Save」ボタンで保存します。
Webコンソールに戻り「Storage」の列が指定したストレージになっていればOKです。
今回は以下に保存するようにしたので、Zoneminderが検知してイベント記録するように、カメラの前へ行って踊り的な動きをして保存してもらいます。
/mnt/yottamaster-raid0/zoneminder/events
正しく保存される場合は、指定した events ディレクトリ下にモニターIDのディレクトリが自動作成され、そこに画像などが保存され始めます。
保存フォルダが存在しなかったり、書き込み権限がなくてイベント記録出来ない場合は /var/log/messages に以下のようなログが記録されます。
[Storage::disk_usage_percent: path /mnt/yottamaster-raid0/zoneminder/events does not exist] at /usr/share/zoneminder/www/includes/Storage.php line 86
以下のようなものもありました。
[Path /mnt/yottamaster-raid0/zoneminder/events does not exist.] at /usr/share/zoneminder/www/includes/Storage.php line 124
rsyslogでログ振り分けしている場合は、振り分け先のzoneminderのログを確認して下さい。
旧HDDのイベント削除
HDDを新しいものに切り替えるのであれば、古いHDDに残っているイベントを全て削除して掃除します。
Webコンソールの上部メニューから「Filters」をクリックします。
特にストレージを追加していない場合、デフォルトで保存されている旧HDDのイベントは「Default」というストレージエリアに保存されていますので、「Storage Area」で「equal to」にし「Default」を選択します。
この条件だけだと、「保存ストレージがDefaultのイベント全て」という意味になりますので、キレイに掃除できます。
その下に「Limit to first」～「results only」というのがありますが、一度に処理する件数なので、一気に大量に削除したい場合はここの数字を大きくして下さい。
左にあるオプションのうち「Delete all matches」にチェックを入れておきます。
これでマッチしたものは全て削除するという意味のフィルタになります。
最後に最下部の「EXECUTE」ボタンをクリックすると削除が始まります。
この画面上では削除の処理状況が確認できないため、Webコンソールに戻ってイベント数とサイズの行を確認すると良いです。
F5キーでページ更新を何度かしてみて、イベントがどんどん減っていくようなら削除中です。
あと、Zoneminderのアップデートや保存先変更などを行っていると、以下のデフォルトのイベント保存先に古いイベントの残骸が残ってしまう場合があるため、確認して不要なイベントがあれば日時などから不要なイベントかどうか確認したのち、削除しておくとスッキリします。
ZoneMinderの「Filters」での削除は、データベースを照会して対応するイベントディレクトリも削除するという動きのため、データベースに無いイベントの場合は events ディレクトリ内に残骸が残ってしまうという仕組みです。
特にデータベースをバックアップから復元すると、その時点で残っているイベント画像などが残りますが、データベースにはイベントが無い状態になります。
こうなると、データベースにないイベントディレクトリが相当数出てくるので、場合によっては数百GB～数TB単位の残骸が出ることがあります。
/var/lib/zoneminder/events/
例えば「モニターID」が「10」の場合は以下のようなディレクトリが残っている場合がありますが、日付があまりに古いようなら単なる残骸なので削除しても構いません。
本当に残骸なら、ZoneMinderの「Filters」で対象モニターIDの一覧を表示してみると、対象日時のイベントが存在しないはずです。
/var/lib/zoneminder/events/10/2020-11-12/
おしまいです。
コメントフォーム