Skip to content

Hetzner Cloud - Volumes

Allgemeine Diskussionen
  • Bedingt durch einige Spielerei an diesem Wochenende, wo ich mal wieder viel ausprobiert habe, bin ich doch zu der Überzeugung gekommen das das Setup von mir nicht sooo schlecht ist, bis auf eine Sache. Bei einem kurzen Schriftwechsel mit dem Nico, hatte ich eine Problem in meinem Setup erkannt. Alle meine Server liegen bei Hetzner im selben Rechenzentrum. Ok, wenn wir uns kurz zurück erinnern, nicht unbedingt die beste Idee.

    Hetzner bietet drei Standorte in Europa an, zwei in Deutschland und einer in Finnland. Somit war klar, der Server mit den Backups muss umziehen 😊

    Also, fangen wir an.

    Snapshot erstellen

    77d3cf6f-62b2-41c8-b66a-a42ed95ab3e1-image.png

    Von dem Server einen Snapshot angelegt. Dabei ist mir direkt ein anderes Problem aufgefallen. Der Snapshot ist 1,4 GB groß, ich habe aber ca. 100 GB an Daten 🤔 Ok, ich hatte da eine schwere Informationslücke, die Volumes werden nicht in die Datensicherung mit aufgenommen, es wird nur der Server gesichert.

    Bitte beachten Sie, dass Snapshots und Backups keine Volumes enthalten, die an Ihren Server angehängt sind.
    Quelle: https://docs.hetzner.com/de/cloud/general/faq

    Ok, dazu später mehr.

    Snapshot transferieren

    Ich habe mir für den Server ein eigenes Projekt erstellt. Dahin habe ich den Snapshot dann transferiert.

    Bildschirmfoto vom 2021-03-21 17-01-47.png

    Server erstellen

    Mit Hilfe dieses Snapshots konnte ich den Server nun neu erstellen. Das hatte auch ganz gut geklappt, bis auf das Volume. Das habe ich später nochmal ausgehangen und erneut angehangen um den automatischen Mount erneut erstellen zu können.

    Dran denken, wenn man Volumes vergrößert, muss man das Filesystem von Hand vergrößern.

    resize2fs /dev/sdx
    

    c2c3b577-9657-49aa-afcf-0893bc834ff2-image.png

    Der Server lief danach und mein Volume war auch vorhanden, aber ohne Daten.

    Volume umziehen

    Da man Volumes nicht von einem Standort zum nächsten schieben kann, musste ich das von Hand mit Bordmitteln lösen. Auch nicht so schwer.

    scp -r /mnt/HC_Volume_1234567/Ordner/ USER@<IPv4>://mnt/HC_Volume_12345678
    

    Danach konnte ich einen Kaffee trinken. Nach relativ kurzer Zeit waren die 100 GB auf dem neuen Volume drauf. Kurz noch die Benutzerrechte anpassen, weil mein Ordner von einem bestimmten Benutzer betreut wird 😉

    Backups

    Dann für den neuen Server die Backup Funktion eingeschaltet.

    Merksatz ☝ Das Backup sichert keine Daten von einem Volume Laufwerk!!

    Servicearbeiten

    Was musste ich noch an meinem Rest-Server machen?

    • Mit Letsencrypt das richtige Zertifikat installieren, nachdem ich den DNS-Eintrag auf den neuen Server eingestellt hatte.

    • Funktionstest. Ein Backup gestartet, lief alles einwandfrei.

    • Erinnerung im Kalender eingerichtet, das ich nächste Woche alles kontrolliere und dann den alten Server abschalte.

    Fazit

    Wieder eine Menge dieses Wochenende gelernt. Und einen Konzeptfehler in meinem Aufbau verbessert. Sollte jetzt das RZ mit den Webservern ausfallen, habe ich noch die Backups im anderen RZ. Sollte das RZ der Backups ausfallen, ist das zu verkraften, da die Webserver ja noch laufen. Somit sollte das jetzt für meine Hobbyserver ausreichend sicher sein.

    Danke Nico, für den entscheidenden Hinweis, das ich was verbessern muss!

    Oder das RZ abbrennt, siehe ovh

  • Rest-Server v0.12.0 released

    Restic
    1
    0 Stimmen
    1 Beiträge
    63 Aufrufe
    Niemand hat geantwortet
  • Star64 lieferbar

    Star64
    1
    0 Stimmen
    1 Beiträge
    51 Aufrufe
    Niemand hat geantwortet
  • Redis - Zweite Instanz

    Redis
    1
    0 Stimmen
    1 Beiträge
    167 Aufrufe
    Niemand hat geantwortet
  • Ubiquiti ER-X - iperf

    Verschoben OpenWRT & Ubiquiti ER-X
    2
    0 Stimmen
    2 Beiträge
    251 Aufrufe
    FrankMF

    Hier noch ein Test von DMZ / LAN und andersrum.

    frank@frank-MS-7C37:~$ iperf3 -c 192.168.5.15 Connecting to host 192.168.5.15, port 5201 [ 5] local 192.168.3.213 port 44052 connected to 192.168.5.15 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 114 MBytes 952 Mbits/sec 314 153 KBytes [ 5] 1.00-2.00 sec 112 MBytes 937 Mbits/sec 259 205 KBytes [ 5] 2.00-3.00 sec 111 MBytes 929 Mbits/sec 210 212 KBytes [ 5] 3.00-4.00 sec 111 MBytes 934 Mbits/sec 235 202 KBytes [ 5] 4.00-5.00 sec 112 MBytes 936 Mbits/sec 263 153 KBytes [ 5] 5.00-6.00 sec 111 MBytes 935 Mbits/sec 255 209 KBytes [ 5] 6.00-7.00 sec 112 MBytes 937 Mbits/sec 313 129 KBytes [ 5] 7.00-8.00 sec 111 MBytes 932 Mbits/sec 296 209 KBytes [ 5] 8.00-9.00 sec 111 MBytes 934 Mbits/sec 258 208 KBytes [ 5] 9.00-10.00 sec 111 MBytes 934 Mbits/sec 292 201 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 936 Mbits/sec 2695 sender [ 5] 0.00-10.00 sec 1.09 GBytes 935 Mbits/sec receiver iperf Done. frank@frank-MS-7C37:~$ iperf3 -R -c 192.168.5.15 Connecting to host 192.168.5.15, port 5201 Reverse mode, remote host 192.168.5.15 is sending [ 5] local 192.168.3.213 port 44058 connected to 192.168.5.15 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 109 MBytes 911 Mbits/sec [ 5] 1.00-2.00 sec 109 MBytes 912 Mbits/sec [ 5] 2.00-3.00 sec 109 MBytes 912 Mbits/sec [ 5] 3.00-4.00 sec 109 MBytes 912 Mbits/sec [ 5] 4.00-5.00 sec 109 MBytes 912 Mbits/sec [ 5] 5.00-6.00 sec 108 MBytes 903 Mbits/sec [ 5] 6.00-7.00 sec 109 MBytes 912 Mbits/sec [ 5] 7.00-8.00 sec 109 MBytes 912 Mbits/sec [ 5] 8.00-9.00 sec 109 MBytes 912 Mbits/sec [ 5] 9.00-10.00 sec 109 MBytes 912 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.06 GBytes 913 Mbits/sec 114 sender [ 5] 0.00-10.00 sec 1.06 GBytes 911 Mbits/sec receiver iperf Done.
  • Kopia - Mit Snapshots arbeiten

    Kopia
    2
    0 Stimmen
    2 Beiträge
    341 Aufrufe
    FrankMF

    Solltet Ihr mal snaps mit dem Status incomplete haben und möchtet diese loswerden

    :~$ kopia snap ls -i USER@HOST:/home/frank 2020-09-10 16:31:45 CEST k89770cab1061e00ada49efc41075ed34 incomplete:canceled 728.8 MB drwxr-xr-x files:8891 dirs:3033 (incomplete) 2020-09-10 16:40:05 CEST k27f028b63299983167cb0b4a0c85df80 incomplete:canceled 153.8 MB drwxr-xr-x files:1052 dirs:324 (incomplete)

    So was passiert z.B. wenn die Internetleitung rumzickt. Jarek meint, das wäre nicht schlimm, beim nächsten Snapshot wird das gefixt und die Daten genutzt, die schon verarbeitet wurden.

  • LUKS verschlüsselte Platte mounten

    Linux
    2
    0 Stimmen
    2 Beiträge
    631 Aufrufe
    FrankMF

    So, jetzt das ganze noch einen Ticken komplizierter 🙂

    Ich habe ja heute, für eine Neuinstallation von Ubuntu 20.04 Focal eine zweite NVMe SSD eingebaut. Meinen Bericht zu dem Thema findet ihr hier. Aber, darum soll es jetzt hier nicht gehen.

    Wir haben jetzt zwei verschlüsselte Ubuntu NVMe SSD Riegel im System. Jetzt klappt die ganze Sache da oben nicht mehr. Es kommt immer einen Fehlermeldung.

    unbekannter Dateisystemtyp „LVM2_member“.

    Ok, kurz googlen und dann findet man heraus, das es nicht klappen kann, weil beide LVM Gruppen, den selben Namen benutzen.

    root@frank-MS-7C37:/mnt/crypthome/root# vgdisplay --- Volume group --- VG Name vgubuntu2 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size <464,53 GiB PE Size 4,00 MiB Total PE 118919 Alloc PE / Size 118919 / <464,53 GiB Free PE / Size 0 / 0 VG UUID lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A --- Volume group --- VG Name vgubuntu System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size <475,71 GiB PE Size 4,00 MiB Total PE 121781 Alloc PE / Size 121781 / <475,71 GiB Free PE / Size 0 / 0 VG UUID jRYTXL-zjpY-lYr6-KODT-u0LJ-9fYf-YVDna7

    Hier oben sieht man das schon mit geändertem Namen. Der VG Name muss unterschiedlich sein. Auch dafür gibt es ein Tool.

    root@frank-MS-7C37:/mnt/crypthome/root# vgrename --help vgrename - Rename a volume group Rename a VG. vgrename VG VG_new [ COMMON_OPTIONS ] Rename a VG by specifying the VG UUID. vgrename String VG_new [ COMMON_OPTIONS ] Common options for command: [ -A|--autobackup y|n ] [ -f|--force ] [ --reportformat basic|json ] Common options for lvm: [ -d|--debug ] [ -h|--help ] [ -q|--quiet ] [ -v|--verbose ] [ -y|--yes ] [ -t|--test ] [ --commandprofile String ] [ --config String ] [ --driverloaded y|n ] [ --nolocking ] [ --lockopt String ] [ --longhelp ] [ --profile String ] [ --version ] Use --longhelp to show all options and advanced commands.

    Das muss dann so aussehen!

    vgrename lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A vgubuntu2 ACHTUNG Es kann zu Datenverlust kommen, also wie immer, Hirn einschalten!

    Ich weiß, das die erste eingebaute Platte mit der Nummer /dev/nvme0n1 geführt wird. Die zweite, heute verbaute, hört dann auf den Namen /dev/nvme1n1. Die darf ich nicht anpacken, weil sonst das System nicht mehr startet.

    /etc/fstab

    # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/vgubuntu-root / ext4 errors=remount-ro 0 1 # /boot was on /dev/nvme1n1p2 during installation UUID=178c7e51-a1d7-4ead-bbdf-a956eb7b754f /boot ext4 defaults 0 2 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=7416-4553 /boot/efi vfat umask=0077 0 1 /dev/mapper/vgubuntu-swap_1 none swap sw 0 0

    Jo, wenn jetzt die Partition /dev/mapper/vgubuntu2-root / anstatt /dev/mapper/vgubuntu-root / heißt läuft nichts mehr. Nur um das zu verdeutlichen, auch das könnte man problemlos reparieren. Aber, ich möchte nur warnen!!

    Nachdem die Änderung durchgeführt wurde, habe ich den Rechner neugestartet. Puuh, Glück gehabt, richtige NVMe SSD erwischt 🙂

    Festplatte /dev/mapper/vgubuntu2-root: 463,58 GiB, 497754832896 Bytes, 972177408 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes

    Nun können wir die Platte ganz normal, wie oben beschrieben, mounten. Nun kann ich noch ein paar Dinge kopieren 😉

  • 0 Stimmen
    1 Beiträge
    775 Aufrufe
    Niemand hat geantwortet
  • Youtube in Grav

    Grav
    1
    0 Stimmen
    1 Beiträge
    501 Aufrufe
    Niemand hat geantwortet