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

  • Happy Birthday Debian

    Allgemeine Diskussionen
    1
    0 Stimmen
    1 Beiträge
    60 Aufrufe
    Niemand hat geantwortet
  • 0 Stimmen
    1 Beiträge
    75 Aufrufe
    Niemand hat geantwortet
  • Rest-Server v0.12.0 released

    Restic
    1
    0 Stimmen
    1 Beiträge
    65 Aufrufe
    Niemand hat geantwortet
  • Linux Mint "Una" Cinnamon 20.3

    Linux
    7
    0 Stimmen
    7 Beiträge
    316 Aufrufe
    FrankMF

    Heute drüber gestolpert, man hat sich auch der alten Version des Thunderbirds angenommen.

    0aa9e265-95b3-4de6-a8c8-b23c5b980f09-grafik.png

    Damit sind zwei wichtige Programme jetzt hoffentlich immer auf dem aktuellsten Stand.

  • Redis - Zweite Instanz

    Redis
    1
    0 Stimmen
    1 Beiträge
    171 Aufrufe
    Niemand hat geantwortet
  • PCIe WIFI6 Karte

    Linux
    4
    0 Stimmen
    4 Beiträge
    248 Aufrufe
    K

    alles gut. wenn zeit und laune, danke

  • LUKS verschlüsselte Platte mounten

    Linux
    2
    0 Stimmen
    2 Beiträge
    656 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
    222 Aufrufe
    Niemand hat geantwortet