Skip to content

Hetzner Cloud - Server läßt sich nicht verschieben!

Linux
  • Wenn ihr mal Probleme habt, einen Server von einem Projekt zu einem anderen zu verschieben, das hatte ich auch 😉

    Bei mir lag es daran, das ich eine Hetzner Firewall an dem Server dran hatte. Also die Verbindung zur Firewall getrennt, dann kann man auch den Server einwandfrei verschieben 🙂

    Firewall danach wieder neu verbinden, wenn gewünscht.

  • 0 Stimmen
    1 Beiträge
    80 Aufrufe
    Niemand hat geantwortet
  • Happy Birthday Debian

    Allgemeine Diskussionen
    1
    0 Stimmen
    1 Beiträge
    59 Aufrufe
    Niemand hat geantwortet
  • Debian Bookworm 12 - Restic

    Linux
    1
    0 Stimmen
    1 Beiträge
    96 Aufrufe
    Niemand hat geantwortet
  • 0 Stimmen
    1 Beiträge
    525 Aufrufe
    Niemand hat geantwortet
  • checkmk - Rest-Server überwachen

    Verschoben checkmk
    1
    0 Stimmen
    1 Beiträge
    348 Aufrufe
    Niemand hat geantwortet
  • Kopia - HTTP/S Server

    Verschoben Kopia
    3
    0 Stimmen
    3 Beiträge
    1k Aufrufe
    FrankMF

    Ich hatte ein paar Probleme, die ich mir teilweise nicht erklären kann 🤔

    Ich möchte den Kopia Server gerne über systemd steuern.

    SystemD [Unit] Description=Kopia Server After=syslog.target After=network.target [Service] Type=simple User=kopia Group=kopia ExecStart=/usr/bin/kopia server --tls-cert-file /home/kopia-server/fullchain.pem --tls-key-file /home/kopia-server/privkey.pem --htpasswd-file /home/kopia-server/.htpasswd --address <IPv4>:51515 Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

    Danach

    systemctl daemon-reload systemctl start kopia-server

    Mit

    systemctl status kopia-server

    kann man sich den Status anzeigen lassen.

    Client Rechner

    Auf dem Client, der das Backup zum Server schicken soll, machen wir dann folgendes.

    USER@HOSTNAME:~$ kopia repo connect server --url=https://<DOMAIN>:51515 --override-username=USER --override-hostname=HOSTNAME Enter password to open repository: Connected to repository API Server. NOTICE: Kopia will check for updates on GitHub every 7 days, starting 24 hours after first use. To disable this behavior, set environment variable KOPIA_CHECK_FOR_UPDATES=false Alternatively you can remove the file "/home/frank/.config/kopia/repository.config.update-info.json".

    Danach steht die Verbindung und wir können Backups hochschieben.

    kopia snapshot create $HOME

    Damit wird das Homeverzeichnis gesichert. Das initiale Backup, hat 30 Minuten gebraucht.

    created snapshot with root kb9e50ff5xxxxxxxxxx265d40a5d0861 and ID cda5c0ffxxxxxxxxxxxxxxa4cb4a367b in 30m28s

    Ein späteres Backup, sieht so aus.

    USER@HOSTNAME:~$ kopia snapshot create $HOME Snapshotting USER@HOSTNAME:/home/frank ... * 0 hashing, 51 hashed (324.8 MB), 8524 cached (6.6 GB), 0 uploaded (0 B), 0 errors 100.0% Created snapshot with root kc20a4xxxxxxxxxxxx745c6c7b37c and ID d7a96eaxxxxxxxxxxx0961018eacffa in 3m12s

    Nach 3 Minuten durch. Zu diesem Zeitpunkt hat sich aber auch nicht wirklich was geändert!

    Fazit

    Das Tool macht immer noch einen sehr guten Eindruck. Die Geschwindigkeit ist sehr gut. Die Anleitung ist leider unzureichend. Da gibt es so viele Möglichkeiten, da braucht es sehr lange, bis man da mal durchsteigt. Zum Glück, ist das was man normalerweise braucht, recht überschaubar. Bis zum produktiven Einsatz braucht das aber bei mir noch eine Menge mehr Tests.

    Was ich noch testen möchte

    Verzeichnis mounten Backup testweise wieder herstellen (zumindestens teilweise)

    Der Test läuft mit Standard Einstellungen, also z.B. ohne Kompression. Das sollte man dann auch mal testen..

    Bitte achtet auf gleiche Versionen auf dem Clienten, wie auf dem Server. Ich meine da ein paar Probleme festgestellt zu haben...

  • Restic - Rootserver als Datenablage nutzen

    Restic
    2
    0 Stimmen
    2 Beiträge
    684 Aufrufe
    FrankMF

    Ok, das erste Backup dauert immer was länger 😉 In meinem Fall 5 Std. 16 Minuten.

    Files: 33408 new, 0 changed, 0 unmodified Dirs: 1 new, 0 changed, 0 unmodified Data Blobs: 20849 new Tree Blobs: 2 new Added to the repo: 6.278 GiB processed 33408 files, 8.604 GiB in 5:16:03 snapshot 5beg1cb3 saved

    Aber, das Schöne ist, das die Backups inkrementell angelegt werden. Das nächste geht schneller 🙂

    open repository repository 3gg202a2 opened successfully, password is correct lock repository load index files using parent snapshot 5beg1cb3 start scan on [/home/frank] start backup on [/home/frank] scan finished in 3.791s: 33788 files, 8.611 GiB Files: 496 new, 74 changed, 33218 unmodified Dirs: 0 new, 1 changed, 0 unmodified Data Blobs: 292 new Tree Blobs: 2 new Added to the repo: 43.661 MiB processed 33788 files, 8.611 GiB in 2:15 snapshot fag41bf7 saved

    Eine tägliche Sicherung sollte dann wohl reichen.

  • NodeBB - Upgrade auf v1.9.0

    NodeBB
    2
    0 Stimmen
    2 Beiträge
    794 Aufrufe
    FrankMF

    Da oben fehlt ein Schritt.

    cd nodebb (or path to where nodebb is installed) ./nodebb stop git fetch git checkout v1.12.x git merge origin/v1.12.x ./nodebb upgrade

    Beim nächsten Upgrade testen.