Komplettbackup / Restore von vServer / Root-Server

  • Hallo Forum!


    Wie erstelle ich ein komplettes Backup eines vServer/Root-Servers und vorallem, wie kann ich dies innert kurzer Zeit restoren? Im Idealfall auch noch automatisch.


    Bislang habe ich das so verstanden:

    1. Offline Snapshot erstellen

    2. Export (via 1.5€ pro Export unabhängig der Grösse, auch bei meinem mickrigen 20 GB vServer)

    3. via FTP auf lokalen PC downloaden (unkomprimiert)

    4. via FTP von lokalem PC zu Netcup uploaden (leider auch unkomprimiert)

    5. .qcow2 einbinden und man ist wieder mit dem Stand des Backups online
    (Dazwischen immer mal wieder länger warten und immer mal wieder neu Logindaten für FTP erhalten)


    Das Image muss also bei einem Restore (der .qcow2 Datei) wieder zurück zu NetCup. In meinem Fall dauert das für eine 16GB Datei mit 20Mbit Upload im besten Fall zwei Stunden.


    Was gibt es für Alternativen, damit der Restore zügiger und automatisch durchgeführt werden kann?


    Ich möchte explizit das Image restoren und nicht neu installieren und danach nur die Daten/Konfigurationen importieren (ein tägliches Backup wird mit dirvish gemacht).


    Wie habt ihr dies gelöst?


    Mit dem Storage Server von Netcup würde so etwas theoretisch gehen. Nur kostet das scheinbar auch 1.5€ pro Export, automatisieren geht auch nicht und der Storage Server kostet schon das mehrfache des vServers (Storage Server ab 16€, vServer ab 3€). Und da weiss ich nicht mal wo das ganze gespeichert ist (womöglich auf dem gleichen Host...). Wunsch wäre da anderen Standort.


    Mit dirvish (rsync+ssh) könnte man sowas selbst zusammenstricken. Dann brauchts nicht mal den 1.5€ Export. Nur bedingt das im Restorefall etwas viel Handarbeit (Rettungsmedium starten, partitionieren, filesystem anlegen, mounten, rsync+ssh, mit dem gerade aktuellen bootloader kämpfen, ... alles in der Console ohne copy/paste). Ein Restore ist immer genau dann nötig, wenn Zeit gerade absolute Mangelware ist.


    Gruss,

    Peter

  • Statt einem Storage Server könntest du auch minimalistisch im Rettungssystem einen Storage Space Share (ab 250GB für 5€) mit NFS einbinden und /dev/sda per dd sichern.

    Oder mit Menüführung z.B. Clonezilla, mit ISO hochladen und booten (zum sichern und restoren).


    Ich hab im Moment nur Filesicherung mit Borgbackup, da mein vServer 160GB SSD hat und ich nicht genug Platz (und Downtime) habe, um ein Image so zu sichern...

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus

  • Wieso hast du kein Copy&Paste? Eigentlich bootest du von einer CD und startest dort einen SSH-Server.


    Wieso musst du per Hand partitionieren? Das machst du doch auch nicht bei einer Installation, oder?


    Ich sichere per rsync den kompletten Server (und versioniere die Sicherungen per BTRFS/ZFS). Bei einem restore würde ich von der Original ISO neu installieren und dann per rsync die Installation auf den aktuellen Stand bringen.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Vielen Dank für die Tips!


    sdellenb: Ja Clonezilla soll ja auch per NFS, könnte klappen. Borgbackup hört sich gut an, kenne ich gar nicht (kenne nur dirvish, welches remote per ssh eine qual ist). Hast du mal ein Borgbackup komplett restored, stimmen danach zB soft- und hardlinks noch?


    vmk: Stimmt, ein SSH Server dort starten würde das lösen. Wenn du nach einiger Zeit wieder die selbe Partitionierung haben möchtest wie auf dem Backup gehts fast nur per Hand. Je nach Distribution und Jahr kanns sonst Unterschiede geben. Hast du gute Erfahrung gemacht, nach einer Installation via Rsync (wohl mit --delete) ein Backup darüber zu pappen?


    Ich tendiere momentan zu ISO booten/Neuinstallation und dann via rsync retour, muss wohl das ganze mal durchspielen.

  • Wir haben einen Ubuntu Server und darauf dann mehrere LXD-Container. Die exportieren wir zweimal täglich auf den netcup Storage-Space. Du kannst natürlich auch nur einen Container verwenden, und die Kapselung quasi nur zum Zwecke der einfachen Sicherung nutzen. Der Restore besteht dann aus Standard-Image installieren, LXD konfigurieren und Image wieder importieren.


    Edit: Der Vorteil hier ist, dass du (fast) keine Downtime hast wenn du als LXD-Storage ZFS oder BTRFS nutzt, weil du dann vor dem Image-Export einen Snapshot machen kannst.

  • Edit: Der Vorteil hier ist, dass du (fast) keine Downtime hast wenn du als LXD-Storage ZFS oder BTRFS nutzt, weil du dann vor dem Image-Export einen Snapshot machen kannst.

    Ist das Ubuntu via ISO installiert worden?


    Oder kann man das ZFS nachträglich einrichten? Wie viel ARC Speicher braucht man?


    Der LXD würde in dem Fall ZFS als Storage benutzen? Macht man dann ein ZFS Snapshot und exportiert das?

  • Die Partitionierung bekommst du ja aber automatisch wieder hin, wenn im Setup bei der ISO genau das auswählst, was du vorher auch gemacht hast. Dafür wird ja eine ks.cfg erstellt. Darüber führst du einfach den Setup aus. Alternativ legst du schnell die Partitionen per Hand an. Ist ja aufregendes.


    Ich habe den Server dann einfach woanders betrieben, da ich immer das Glück eines Totalschadens hatte.


    Das Updaten der Installation mit rsync gegenüber dem aktuellen Stand verändert ja kaum was am System. Du setzt ja sicherlich eine LTS-Version ein und da bleiben die Versionen der Software/etc ja alle stabil.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Ist das Ubuntu via ISO installiert worden?

    -> Nein, als Image. Bei der Erstellung "Bereitstellung in kleiner Partition" auswählen, dann bleibt der Rest frei.


    Oder kann man das ZFS nachträglich einrichten? Wie viel ARC Speicher braucht man?

    -> Die ZFS-Partition wird während der LXD Initialisierung erstellt, wenn du angibst, dass ein existierendes Blockdevice verwendet werden soll.


    Der LXD würde in dem Fall ZFS als Storage benutzen? Macht man dann ein ZFS Snapshot und exportiert das?

    -> LXD (bzw. mein Export-Script) stoppt den Container, macht einen Snapshot, startet den Container wieder und exportiert dann den Snapshot als Image.


    Nach mehreren Tests empfehle ich allerdings BTRFS als LXD-Storage. Wichtigster Grund ist, dass eine Defragmentierung bzw. fstrim unterstützt wird. So weiß das SCP, welche Blöcke auf der BTRFS-Partition frei sind und SCP-Snapshots funktionieren weiterhin. Auf dem Produktiv-Server zeigt das SCP aktuell 580 von 468GB belegt, da wir dort noch auf ZFS setzen.. ;)


    Werbung in eigener Sache: Wir nutzen für den Import/Export das folgende von mir gebaute Script: https://github.com/janxb/ServerUtils/blob/master/lxd-backup

  • janxb Das muss ich mal ausprobieren. Da könnte es sich rentieren einen Root-Server nochmal neu aufzusetzen, da die Dienste dort mit ein paar Konfigs wiederherstellbar sein müssten. Evtl. sind die Container auch weitgehend per Ansible deploybar.

  • Reguläres Windows Backup einmal am Tag auf eine getrennte Partition.

    Diese Partition und ein paar kritischen Verzeichnisse werden von einem Drittanbieter Dienst überwacht und bei selbigem in seiner eigenen Cloud versioniert gesichert.

  • janxb Ich habe das Backup Script inzwischen ausprobieren können und dann gleich noch ein paar Fragen dazu: das Script stopped ja die Container für den Snapshot. Ist das zwingend nötig?

    Das Script hat auch auf einem ext4 Filesystem funktioniert, ohne dass das Filesystem Snapshots unterstützt. Ist es dann nötig BTRFS zu verwenden?

  • Mir sind offline snapshots im allgemeinen deutlich lieber, da ich mir dann sicher sein kann, dass alle Services in konsistentem Zustand sind und beim restore auch wieder starten. Die Scripte sind halt auch immer auf meine konkreten Bedürfnisse angepasst..


    Zum Thema BTRFS: Den Snapshot mache ich, damit ich den Container danach sofort wieder starten kann, ohne auf den Image-Export zu warten. Unter EXT4 sind Snapshots einfach Vollkopien und dauern daher deutlich länger. BTRFS oder ZFS hat den Vorteil, dass die snapshots deutlich schneller gemacht sind und man daher nur ein paar Sekunden downtime pro Container hat.