NC: Backups

[Rüdiger Kupper]

Sobald unser NC-Server in den Produktivbetrieb geht, braucht der cloud-Rechner (und ev. auch die Server apache und collabora?) braucht eine Backup-Lösung, die erlaubt, im Fall eines Defekts den kompletten Server und die Datenbank zügig wiederherzustellen.

Wir könnten die rsnapshot-Lösung verwenden, die wir bereits für den paedml umd den Verwaltungsrechner nutzen. Die Datenbank sollte zusätzlich über einen SQL-Dump gesichert werden.

@bau

bietet der Proxmox vieleicht eine einfachere Backup-Lösung?

[bau]

Proxmox kann so ein Backup erstellen. Dazu macht der dann ein LVM-Snapshot und davon ein Backup.
Die Datenbank allerding sollte mit mysqldump erstellt werden.

[Rüdiger Kupper]

Ist das denn (von der DB abgesehen) die bessere Lösung als der Bsckup-Server? Oder bleiben wir lieber bei der bewährten Lösumg?

[bau]

Der Backup-Server ist für den Fileserver die beste Lösung, da sich dort ständig einzelne Dateien ändern.
Bei den VM ist es so, dass man am besten einen LVM-Snapshot macht und dann den Ist-Zustand in ein File sichert.
Dann kann man im Fall eines Defekts die VM auf jedem beliebigen Proxmox einspielen und die läuft dann sofort. Ich habe gerade erst auf PromoxLS aufgeräumt, da waren bei einigen VM die virtuellen HDDs noch als Datei im RAW-Format abgelegt. Ich habe die nun alle ins LVM gelegt - geht ganz einfach:

• LV in gleicher Größe anlegen
• Image-Datei (RAW) mit dd in das LV kopieren
• Config-Datei so anpassen, dass die HDD vom anderen Storage genommen wird

Dabei habe ich die noch vorhandenen RAW-Files zusammen mit der Config auf eine externe Sicherungsplatte übertragen - die würde nun auf jedem anderen ProxMox auch laufen.

[Rüdiger Kupper]

Verstehe ich noch nicht ganz: Du machst einen LVM-Snapshot umd dann? Dann hast Du doch immern noch ein komplettes Dateisystem. Wie speicherst Du das in einem File?

[bau]

dd if=/dev/mapper/vg_XY-vm--100--disk--1 of=/mnt/backup/file bs=8M

Ja, damit erhalte ich das komplette Filesystem der VM. Das Ganze wird dann gepackt und mit der Config irgendwo abgelegt (z.B. auf eine externe Platte). Im Fall der Fälle kann der dd die komplette VM einfach wieder ins LVM zurückspielen. Config-Datei ablegen und die VM läuft wieder. Lediglich die Datenbank und ggf irgendwelche Files, die sich öfters mal ändern müssen regelmäßig gesichert werden.

[Rüdiger Kupper]

Habe heute erst mal ein manuelles Backup gemacht und auf NC 22.2.0 aktualisiert.

[Rüdiger Kupper]

Replying to bau:

Proxmox kann so ein Backup erstellen. Dazu macht der dann ein LVM-Snapshot und davon ein Backup.

Beim meinem letzten Versuch, ist dieser Weg fehlgeschlagen mit ominösen Zugriff-Verweigert-Fehlern. Ich vermute, es gibt noch irgendwelche Überbleibsel von meinen anfänglichen Experimenten, den Container von unpriviligiert nach priviligiert zu ändern (und wieder zurück). Dabei sind vermutlich Dateien zurückgeblieben, die jetzt ungültige user-ids haben und daher von außerhalb des Containers wirklich nicht gelesen werden können.

Das ist unschön und muss ich irgendwie beheben. Eine Möglichkeit ist, dass ich auf die Suche nach den ungültigen user-ids gehe und versuche, die zu korrigieren.

Die andere Alternative wäre, ein Backup von NC und der Datenbank zu machen, wie es das NC-Manual erklärt, also von innerhalb des Containers. Und dieses Backup dann *in einem neuen Container* wiederherzustellen. Doch auch da kann es wieder andere Probleme geben.

So oder so, wir brauchen eine funktionierende Backup-Lösung, die nicht an diesem Id-Problem krankt. Ich würde das gerne in den Osterferien lösen, denn bevor ich kein wirklich vertrauenswürdiges Backup habe, möchte ich das anstehende Upgrade auf die neue Hauptversion von Nextcloud (Version 23) nicht durchführen, das ist mir zu heikel.

Im schlimmsten Fall, wenn ich die IDs nicht korrigiert bekomme, müsste ich in einem neuen Container Nextcloud noch einmal nach Anleitung "von Scratch" neu installieren und dann unsere Config und unser data-Verzeichnis rüberkopieren.

Jedenfalls brauche ich dafür eine etwas längere Downtime, also peile ich dafür die Ferien an.

@bau

Ist auf dem proxmoxls2 noch genügend Platz um notfalls einen zweiten NC-Server vorübergehend parallel aufzusetzen? Damit ich einmal testen kann, ob meine Backups funktionieren?

[bau]

Die Idee, ein Backup-Next-Cloud zu haben ist nicht schlecht! Dann kannst du in Zukunft ganz entspannt auf dem Backup ein Upgrade machen und testen und erst anschließend das Hauptsystem upgraden - also die Operation am "offenen Herzen" vermeiden.

Warum die Frage nach dem Platz? Du bist doch selbst Admin - oder?

root@proxmoxls2:~# pvs
  PV         VG      Fmt  Attr PSize    PFree  
  /dev/md0p1 storage lvm2 a--   465,63g 465,63g
  /dev/md1p1 storage lvm2 a--   465,63g 333,63g
  /dev/sdc3  pve     lvm2 a--  <111,29g  13,87g

root@proxmoxls2:~# vgs
  VG      #PV #LV #SN Attr   VSize    VFree   
  pve       1   7   0 wz--n- <111,29g   13,87g
  storage   2   2   0 wz--n- <931,27g <799,27g

root@proxmoxls2:~# lvs
  LV            VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data          pve     twi-aotz--  59,66g             53,02  3,06                            
  root          pve     -wi-ao----  27,75g                                                    
  swap          pve     -wi-ao----   8,00g                                                    
  vm-102-disk-0 pve     Vwi-aotz--   3,00g data        94,71                                  
  vm-103-disk-0 pve     Vwi-aotz--  20,00g data        98,01                                  
  vm-104-disk-0 pve     Vwi-aotz--   2,00g data        92,96                                  
  vm-105-disk-1 pve     Vwi-aotz--   8,00g data        91,67                                  
  vm-100-disk-0 storage -wi-a-----  32,00g                                                    
  vm-101-disk-0 storage -wi-ao---- 100,00g    

Ich finde, das sieht doch gut aus - oder?
Die Cloud-VM ist VM 101, da hatten wir 100GB vorgesehen:

root@cloud:~# df
Filesystem                           1K-blocks      Used Available Use% Mounted on
/dev/mapper/storage-vm--101--disk--0 102687672  40189544  57238864  42% /

Im storage sind noch fast 1TB frei, das sollte genügen.
(Keine Ahnung, warum die vHDD der anderen Maschinen im PVE liegen, das ist eventuell etwas unglücklich (nicht aufgepasst bei der Einrichtung?) - ToDo: LVs in storage umziehe (ACHTUNG: Dazu sollte die jeweilige VM angehalten werden!))

Vorgehensweise für ein Backup ist aber ganz einfach, weil das LVs sind:

• Snapshot erstellen mit LVM, zB Name vm-101-disk-0-snap:

    lvcreate -L100% -s -n vm-101-disk-0-snap /dev/storage/vm-101-disk-0
  

• Ab sofort wird die VM weiter Daten in vm-101-disk-0 ändern, deren Originale in vm-101-disk-0-snap landen, alles läuft problemlos weiter.
• Das komplette Snap kann nun per dd in ein neu zu erzeugendes LV (zB vm-101-disk-0-copy) kopiert werden:

   dd if=/dev/storage/vm-101-disk-0-snap of=/dev/storage/vm-101-disk-0-copy -bs=8M
  

  Dabei können definitiv keine Fehler auftreten, da der Snapshot statisch bleibt!
• Anschließend kann die neue vHDD an die neue VM angehängt werden (das Config-File der alten VM kann einfach kopiert und angepasst (andere IPs, andere vHDD) werden).

[Rüdiger Kupper]

Eine Möglichkeit ist, dass ich auf die Suche nach den ungültigen user-ids gehe und versuche, die zu korrigieren.

Sieht aus, als wäre mir das heute gelungen!

• vzdump starten, Zugriffsfehler notieren
• Dateisystem des Containers von außen mounten:
• pct stop 101
• pct mount 101
• betreffende Pfade löschen (konnten ohnehin von innerhalb des Containers nicht gelesen werden, macht also nichts kaputt)
• pct unmount 101

Vzdump läuft jetzt ohne Zugriffsfehler durch! Scheitert zwar am fehlenden Speicherplatz für das Backup, doch das liegt daran, dass das ins Root-FS in VG pve geht. Da ist einfach nicht genug frei.

Das ist super, damit haben wir jetzt die Möglichkeit, einen Probe-Server aufzusetzen, wie Du vorschlägst. Und wir haben die Option, den Container von unpriviligiert auf priviligiert zu portieren – das geht nur mit einem vzdump-Backup.

Sehr gut!

[Rüdiger Kupper]

Warum die Frage nach dem Platz? Du bist doch selbst Admin - oder?

Weil das Dein Wirkungsgebiet ist. Du hast die Proxmox-Server aufgesetzt. Ich bin Nutzer. Du hast den Überblick und kennst Dich damit aus. Ich habe eher Anwenderwissen. Daher ist es logisch, dass ich Dich frage.

[bau]

Das ist nett von dir - in Zukunft reicht eine Information.

[Rüdiger Kupper]

Ich habe nun auf dem proxmoxls2 in der VG „storage“ ein 200GB-LV „backups“ eingerichtet und nach /mnt/backups gemountet. (Und im proxmox-Webinterface als Speicherort für vzdumps konfiguriert.)

Backup des cloud-Containers ist grade durchgelaufen (mittels vzdump, das ist das normale Proxmox-Tool und nutzt rsync/tar/zip. Proxmox kann das auch regelmäßig als Cronjob machen, das sollten wir wohl mal konfigurieren. Mögliche Speicherorte wären auch der backup-Server (per NFS) oder das Gluster slow-storage.

[bau]

Ich schau mir die config mal an, für ein Restore in einer separaten Maschine (als Test-Backup) müssen andere IPs konfiguriert werden.

[Rüdiger Kupper]

Und andere MACs, doch ich vermute, die vergibt Proxmox zufällig, wenn man einen neuen Container anlegt.

[bau]

Man kann auch per Buttonklick neue MACs vergeben lassen.