Eine Western Digital My Book Essential externe Festplatte mit 1 TB Kapazität soll als Backup Laufwerk nächtlich die Datensicherung eines virtualisierten Fileservers aufnehmen der unter Proxmox mit Linux Debian 9.3 läuft.
Es geht um die VM 100 (Fileserver). 
Da die Festplatte an der physikalischen Maschine angeschlossen ist, kennt nur die Virtualisierungssoftware Proxmox die Ports an die etwas angeschlossen ist. Damit bewegen wir uns an dieser Stelle nur in der Virtualisierungssoftware.
Über die Konsole des Knotens (proxmox) auf die Maschine einloggen und die angeschlossenen Geräte und ihre Parametrierung abfragen mit:
root@proxmox:~# lsusb -t
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
|__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=usbfs, 5000M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
|__ Port 5: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 5: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 6: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
root@proxmox:~#
Die Gerätenummer wird vom System automatisch vergeben, unabhängig davon, an welchem USB-Port das Gerät angeschlossen ist. Wird das Gerät getrennt und neu angeschlossen, wird eine neue Gerätenummer vergeben und ist ggf. neu einzubinden (dies auch beim Server herunterfahren oder Serverausfall). Zu sehen sind am Bus 2 die Tastatur und die Maus. Wo hingegen die WD HDD an Bus 6 / Port 2 hängt.
Hier ist nun ebenfalls zu sehen, daß einige Treiber für USB 2.0 (480M) und USB 3.0 (5000M) installiert sind. Die WD HDD hängt an einem USB 3.0 Port, der an die VM 100 durchgereicht werden muß.
Zum Ermitteln der entsprechenden Ports kann auch das Proxmox inherente Programm qm monitor herangezogen werden. Dabei ist 100 auch hier die Bezeichnung der entsprechenden VM (siehe auch Abbildung oben).
root@proxmox:~# qm monitor 100
Entering Qemu Monitor for VM 100 – type ‚help‘ for help
qm> info usbhost
Bus 2, Addr 4, Port 1.6, Speed 1.5 Mb/s
Class 00: USB device 04f3:0210, PS/2+USB Mouse
Bus 2, Addr 3, Port 1.5, Speed 1.5 Mb/s
Class 00: USB device 1267:0103
Bus 6, Addr 2, Port 2, Speed 5000 Mb/s
Class 00: USB device 1058:1130, My Book 1130
qm> q
root@proxmox:~#
Hiermit ist die Darstellung auch etwas klarer. *)
Diese beiden für die Platte ermittelten Werte, Bus 6 und Port 2, werden in die Konfigurationsdatei der entsprechenden VM eingetragen.
root@proxmox:/etc/pve/qemu-server# ls -al
total 2
drwxr-xr-x 2 root www-data 0 Jan 19 08:31 .
drwxr-xr-x 2 root www-data 0 Jan 19 08:31 ..
-rw-r—– 1 root www-data 299 Jan 25 13:23 100.conf
-rw-r—– 1 root www-data 296 Jan 19 10:00 101.conf
-rw-r—– 1 root www-data 301 Jan 19 10:01 102.conf
-rw-r—– 1 root www-data 298 Jan 19 09:58 103.conf
root@proxmox:/etc/pve/qemu-server#
Mit dem Befehl
root@proxmox:/etc/pve/qemu-server# qm set 100 -usb0 host=6-2,usb3=yes
wird der VM 100 mittgeteilt, daß Bus 6 und Port 2 ein usb3 port ist und mit 5000MBit/s bedient wird. Der Befehl antwortet mit
update VM 100: -usb0 host=6-2,usb3=yes
root@proxmox:/etc/pve/qemu-server#
Die Daten trägt der Befehl gleich in die Konfigurationsdatei ein.
Die VM 100 sollte nach dem Eintrag gestoppt werden und neu gestartet. Ein ‚reboot‘ reicht nicht aus! Eine Kontrolle mit qm zeigt, daß die Einbindung gelungen ist.
root@proxmox:/etc/pve/qemu-server# qm monitor 100
Entering Qemu Monitor for VM 100 – type ‚help‘ for help
qm> info usb
Device 0.2, Port 1, Speed 12 Mb/s, Product QEMU USB Tablet, ID: tablet
Device 1.1, Port 1, Speed 5000 Mb/s, Product My Book 1130, ID: usb0
qm>
Damit ist allerdings erst die Hardware an die VM angeschlossen und das Betriebsysstem kennt die Platte noch nicht. Deshalb wird nun per Konsole auf die VM 100 zugegriffen, um die Platte dem Betriebssystem bekanntzumachen und für Lesen und Schreiben anzuschließen.
Ab hier wird auf dem Fileserver VM 100 gearbeitet.
root@itc-fileserver:/# fdisk -l
Disk /dev/sda: 1 TiB, 1099511627776 bytes, 2147483648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8d919602
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 58593279 58591232 28G 83 Linux
/dev/sda2 58595326 2147481599 2088886274 996,1G 5 Extended
/dev/sda5 58595328 66979839 8384512 4G 82 Linux swap /Solaris
/dev/sda6 66981888 2147481599 2080499712 992,1G 83 Linux
Disk /dev/sdb: 931,5 GiB, 1000170586112 bytes, 1953458176 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00073856
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 1953458175 1953456128 931,5G 83 Linux
root@itc-fileserver:/#
/dev/sda zeigt die eingebundene Platte des Fileservers mit der 28GB großen Systempartition als sda1 und die extendet Partition sda2, die den Swap-Speicher sda5 aufnimmt und 992GB für die Datenpartition sda6.
/dev/sdb ist die nun über USB eingebundene externe WD Festplatte.
Mit dem Befehl blkid lassen sich die Geräteidentifizierung (UUID) und die Dateisysteme der Partitionen ermitteln. Das ist für den Befehl mount und den Eintrag in die /etc/fstab erforderlich.
root@itc-fileserver:/# blkid
/dev/sda1: LABEL=“SYSTEM“ UUID=“cff701bb-173f-4108-b963-5b148cf13983″ UUID_SUB=“fb5d4d5d-74cc-4281-8303-b5c2da6b6a76″ TYPE=“btrfs“ PARTUUID=“8d919602-01″
/dev/sda5: UUID=“34c928d2-6a21-4fca-b7b8-39bb2622ec11″ TYPE=“swap“ PARTUUID=“8d919602-05″
/dev/sda6: LABEL=“data“ UUID=“f0bf01fe-e6b7-4f8c-886e-1dadb83ab41f“ TYPE=“xfs“ PARTUUID=“8d919602-06″
/dev/sdb1: UUID=“8f0def20-935f-4eb9-aca7-185c8e71954b“ TYPE=“ext4″ PARTUUID=“00073856-01″
root@itc-fileserver:/#
Da nun bekannt ist, daß die externe Festplatte mit ext4 formatiert ist, kann zum Ausprobieren die Platte mittels mount eingebunden werden. Damit läßt sich erst einmal testen, ob der Zugriff überhaupt klappt. Dazu wird ein Verzeichnis vorbereitet, wohinein die Platte angebunden wird. Ich habe mich entschieden die Platte bei /mnt mit einem eigenen Verzeichnis 1tb einzubinden.
cd /mnt
mkdir 1tb
mount –t ext4 /dev/sdb1 /mnt/1tb
Wechselt man nun in das Verzeichnis 1tb sind die in der root der WD Festplatte liegenden Dateien und Verzeichnisse zu sehen.
Normalerweise laufen Server durch und werden selten neu gestartet. Es kann jedoch sein, daß nach einem Stromausfall der Selbststart zwar klappt aber die Datensicherung dann nicht mehr gewährleistet ist. Deshalb wird die Platte in die fstab eingetragen, um bei einem Neustart auch diese Verbindung wieder herzustellen.
Mit einem Editor wie nano die /etc/fstab öffnen und die Zeilen
# Externe Hdd 1TB Western Digital als Backup
UUID=8f0def20-935f-4eb9-aca7-185c8e71954b /mnt/1tb/ ext4 defaults 0 2
nachtragen.
Die UUID ist die eindeutigste Lösung zum Erkennen der Festplatte. Der Einbindepunkt /mnt/1tb ist ebenfalls festgelegt und das Dateisystem ist mit blkid ermittelt worden. ‚defaults‘ setzt die Standardoptionen für die üblichen Schreib- und Lesevorgänge der Festplatte. Die 0 steht für Dump und wird von Linux ignoriert. Die letzte Spalte gibt die Überprüfung des Dateisystems an. 0=keine Überprüfung, 1=Systempartition prüfen, 2=alle weiteren Partitionen nacheinander prüfen.
Mit einem über cron zu festen Zeiten gestartetes Backup-Script ist nun eine Sicherung sehr leicht zu realisieren. **)
Update 15.04.2019
Nach einem Update ist unbedingt zu prüfen, ob die Einbindung noch besteht. Es ist möglich, daß die Verbindung unterbrochen wird und die Datensicherung deshalb nicht mehr funktioniert.
Update 09.08.2019:
Wird die externe Festplatte abgezogen, um z.B. Hardware im Rechner zu tauschen oder den Standort zu wechseln, ist es möglich, das die entsprechende VM nicht mehr startet und in den Emergency Mode wechselt. Die Lösung steht in You are in emergency mode ….
Alles wieder abbauen
Zum Entfernen der Festplatteneinbindung sind nacheinander einige Dinge zu befolgen …
1. Wechsel in die Virtualisierung (PROXMOX)
2. es dürfen keine Schreib- oder Lesezugriffe mehr erfolgen
3. den qemu monitor für die VM auf der Kommandozeile aufrufen
– qm monitor VMID (z.B. qm monitor 100)
4. auf der Kommandozeile folgendes eingeben <GeräteID> und die verbundene USB-Adresse (z.B. usb0)
device_del <GeräteID>
Nun sollte das USB-Gerät von der VM getrennt sein, wird aber immer noch am Host angezeigt, bis die VM gestoppt und anschließend wieder gestartet wird.
Um den Eintrag aus der Konfiguration wieder zu entfernen, ist der Befehl
qm set VMID -delete ‚usbX‘
aufzurufen, wobei usbX die ID des verwendeten USB-Ports ist (in diesem Fall war es USB 0).
Achtung, dies klappt nicht bei einer laufenden VM.
.
.
.
.
*) Nach einem Hardwarewechsel war die ext. 1TB-Platte zuerst nicht mehr auflistbar, obwohl es alles USB3.0 Gen1 Ports waren, die zu USB 2.0 kompatibel sind.
Erst nach einigem hin und her probieren wurde sie wieder gefunden. Dort war die Platte allerdings nur mit 480M, also USB2.0 angebunden. Gen1 ist vermutlich zum alten USB3.0 inkompatibel.
Die gewünschten 5000M waren erst wieder möglich, als die Platte an einem USB3.1 Gen2 Typ-A Port angeschlossen war (rote Lasche), obwohl dieser Port bereits 10.000M leistet. Aber da kam dann die Platte wohl nicht mehr mit.
[Das neue Board: X470 AORUS ultra gaming]
**) Beim Backupscript auf den leidigen rsync Fehler „skipping directory .“ achten.
