Proxmox Backup Client
https://forum.proxmox.com/threads/proxmox-pve-host-backup-and-desaster-recovery-mit-pbs.93485/
https://pbs.proxmox.com/docs/backup-client.html#client-creating-backups
https://pbs.proxmox.com/docs/installation.html
Backup Client Usage
The command line client for Proxmox Backup Server is called proxmox-backup-client.
Backup Repository Locations
The client uses the following format to specify a datastore repository on the backup server (where username is specified in the form of user@realm):
[[username@]server[:port]:]datastore
The default value for username is root@pam. If no server is specified, the default is the local host (localhost).
You can specify a port if your backup server is only reachable on a non-default port (for example, with NAT and port forwarding configurations).
Note that if the server uses an IPv6 address, you have to write it with square brackets (for example, [fe80::01]).
You can pass the repository with the --repository command line option, or by setting the PBS_REPOSITORY environment variable.
Below are some examples of valid repositories and their corresponding real values:
| Example | User | Host:Port | Datastore |
|---|---|---|---|
| mydatastore | root@pam |
localhost:8007 | mydatastore |
| myhostname:mydatastore | root@pam |
myhostname:8007 | mydatastore |
| user@pbs@myhostname:mydatastore | user@pbs |
myhostname:8007 | mydatastore |
| user@pbs!token@host:store | user@pbs!token |
host:8007 | store |
| 192.168.55.55:1234:mydatastore | root@pam |
192.168.55.55:1234 | mydatastore |
| [ff80::51]:mydatastore | root@pam |
[ff80::51]:8007 | mydatastore |
| [ff80::51]:1234:mydatastore | root@pam |
[ff80::51]:1234 | mydatastore |
Environment Variables
PBS_REPOSITORY- The default backup repository.
PBS_PASSWORD- When set, this value is used as the password for the backup server. You can also set this to an API token secret.
PBS_PASSWORD_FD,PBS_PASSWORD_FILE,PBS_PASSWORD_CMD- Like
PBS_PASSWORD, but read data from an open file descriptor, a file name or from the stdout of a command, respectively. The first defined environment variable from the order above is preferred. PBS_ENCRYPTION_PASSWORD- When set, this value is used to access the secret encryption key (if protected by password).
PBS_ENCRYPTION_PASSWORD_FD,PBS_ENCRYPTION_PASSWORD_FILE,PBS_ENCRYPTION_PASSWORD_CMD- Like
PBS_ENCRYPTION_PASSWORD, but read data from an open file descriptor, a file name or from the stdout of a command, respectively. The first defined environment variable from the order above is preferred. PBS_FINGERPRINT- When set, this value is used to verify the server certificate (only used if the system CA certificates cannot validate the certificate).
ALL_PROXY- When set, the client uses the specified HTTP proxy for all connections to the backup server. Currently only HTTP proxies are supported. Valid proxy configurations have the following format: [http://][user:password@]<host>[:port]. Default port is 1080, if not otherwise specified.
Note
The recommended solution for shielding hosts is using tunnels such as wireguard, instead of using an HTTP proxy.
Note
Passwords must be valid UTF-8 and may not contain newlines. For your convenience, Proxmox Backup Server only uses the first line as password, so you can add arbitrary comments after the first newline.
Output Format
Most commands that produce output support the --output-format parameter. This accepts the following values:
text- Text format (default). Structured data is rendered as a table.
json- JSON (single line).
json-pretty- JSON (multiple lines, nicely formatted).
Also, the following environment variables can modify output behavior:
PROXMOX_OUTPUT_FORMAT- Defines the default output format.
PROXMOX_OUTPUT_NO_BORDER- If set (to any value), do not render table borders.
PROXMOX_OUTPUT_NO_HEADER- If set (to any value), do not render table headers.
Note
The text format is designed to be human readable, and not meant to be parsed by automation tools. Please use the json format if you need to process the output.
Creating Backups
This section explains how to create a backup from within the machine. This can be a physical host, a virtual machine, or a container. Such backups may contain file and image archives. There are no restrictions in this case.
Note
If you want to backup virtual machines or containers on Proxmox VE, see Proxmox VE Integration.
For the following example, you need to have a backup server set up, have working credentials, and know the repository name. In the following examples, we use backup-server:store1.
# proxmox-backup-client backup root.pxar:/ --repository backup-server:store1
Starting backup: host/elsa/2019-12-03T09:35:01Z
Client name: elsa
skip mount point: "/boot/efi"
skip mount point: "/dev"
skip mount point: "/run"
skip mount point: "/sys"
Uploaded 12129 chunks in 87 seconds (564 MB/s).
End Time: 2019-12-03T10:36:29+01:00
This will prompt you for a password, then upload a file archive named root.pxar containing all the files in the / directory.
Caution
Please note that proxmox-backup-client does not automatically include mount points. Instead, you will see a short skip mount point message for each of them. The idea is to create a separate file archive for each mounted disk. You can explicitly include them using the --include-dev option (i.e. --include-dev /boot/efi). You can use this option multiple times for each mount point that should be included.
The --repository option can get quite long and is used by all commands. You can avoid having to enter this value by setting the environment variable PBS_REPOSITORY. Note that if you would like this to remain set over multiple sessions, you should instead add the below line to your .bashrc file.
# export PBS_REPOSITORY=backup-server:store1
After this, you can execute all commands without having to specify the --repository option.
A single backup is allowed to contain more than one archive. For example, if you want to back up two disks mounted at /mnt/disk1 and /mnt/disk2:
# proxmox-backup-client backup disk1.pxar:/mnt/disk1 disk2.pxar:/mnt/disk2
This creates a backup of both disks.
If you want to use a namespace for the backup target, you can add the --ns parameter:
# proxmox-backup-client backup disk1.pxar:/mnt/disk1 disk2.pxar:/mnt/disk2 --ns a/b/c
The backup command takes a list of backup specifications, which include the archive name on the server, the type of the archive, and the archive source at the client. The format is:
<archive-name>.<type>:<source-path>
Common types are .pxar for file archives and .img for block device images. To create a backup of a block device, run the following command:
# proxmox-backup-client backup mydata.img:/dev/mylvm/mydata
Excluding Files/Directories from a Backup
Sometimes it is desired to exclude certain files or directories from a backup archive. To tell the Proxmox Backup client when and how to ignore files and directories, place a text file named .pxarexclude in the filesystem hierarchy. Whenever the backup client encounters such a file in a directory, it interprets each line as a glob match pattern for files and directories that are to be excluded from the backup.
The file must contain a single glob pattern per line. Empty lines and lines starting with # (indicating a comment) are ignored. A ! at the beginning of a line reverses the glob match pattern from an exclusion to an explicit inclusion. This makes it possible to exclude all entries in a directory except for a few single files/subdirectories. Lines ending in / match only on directories. The directory containing the .pxarexclude file is considered to be the root of the given patterns. It is only possible to match files in this directory and its subdirectories.
Note
Patterns without a leading / will also match in subdirectories, while patterns with a leading / will only match in the current directory.
\ is used to escape special glob characters. ? matches any single character. * matches any character, including an empty string. ** is used to match current directory and subdirectories. For example, with the pattern **/*.tmp, it would exclude all files ending in .tmp within a directory and its subdirectories. [...] matches a single character from any of the provided characters within the brackets. [!...] does the complementary and matches any single character not contained within the brackets. It is also possible to specify ranges with two characters separated by -. For example, [a-z] matches any lowercase alphabetic character, and [0-9] matches any single digit.
The order of the glob match patterns defines whether a file is included or excluded, that is to say, later entries override earlier ones. This is also true for match patterns encountered deeper down the directory tree, which can override a previous exclusion.
Note
Excluded directories will not be read by the backup client. Thus, a .pxarexclude file in an excluded subdirectory will have no effect. .pxarexclude files are treated as regular files and will be included in the backup archive.
For example, consider the following directory structure:
# ls -aR folder
folder/:
. .. .pxarexclude subfolder0 subfolder1
folder/subfolder0:
. .. file0 file1 file2 file3 .pxarexclude
folder/subfolder1:
. .. file0 file1 file2 file3
The different .pxarexclude files contain the following:
# cat folder/.pxarexclude
/subfolder0/file1
/subfolder1/*
!/subfolder1/file2
# cat folder/subfolder0/.pxarexclude
file3
This would exclude file1 and file3 in subfolder0 and all of subfolder1 except file2.
Restoring this backup will result in:
ls -aR restored
restored/:
. .. .pxarexclude subfolder0 subfolder1
restored/subfolder0:
. .. file0 file2 .pxarexclude
restored/subfolder1:
. .. file2
Encryption
Proxmox Backup supports client-side encryption with AES-256 in GCM mode. To set this up, you first need to create an encryption key:
# proxmox-backup-client key create my-backup.key
Encryption Key Password: **************
The key is password protected by default. If you do not need this extra protection, you can also create it without a password:
# proxmox-backup-client key create /path/to/my-backup.key --kdf none
Having created this key, it is now possible to create an encrypted backup, by passing the --keyfile parameter, with the path to the key file.
# proxmox-backup-client backup etc.pxar:/etc --keyfile /path/to/my-backup.key
Password: *********
Encryption Key Password: **************
...
Note
If you do not specify the name of the backup key, the key will be created in the default location ~/.config/proxmox-backup/encryption-key.json. proxmox-backup-client will also search this location by default, in case the --keyfile parameter is not specified.
You can avoid entering the passwords by setting the environment variables PBS_PASSWORD and PBS_ENCRYPTION_PASSWORD.
Using a Master Key to Store and Recover Encryption Keys
You can also use proxmox-backup-client key to create an RSA public/private key pair, which can be used to store an encrypted version of the symmetric backup encryption key alongside each backup and recover it later.
To set up a master key:
- Create an encryption key for the backup:
# proxmox-backup-client key create creating default key at: "~/.config/proxmox-backup/encryption-key.json" Encryption Key Password: ********** ...
The resulting file will be saved to
~/.config/proxmox-backup/encryption-key.json. - Create an RSA public/private key pair:
# proxmox-backup-client key create-master-key Master Key Password: ********* ...
This will create two files in your current directory,
master-public.pemandmaster-private.pem. - Import the newly created
master-public.pempublic certificate, so thatproxmox-backup-clientcan find and use it upon backup.# proxmox-backup-client key import-master-pubkey /path/to/master-public.pem Imported public master key to "~/.config/proxmox-backup/master-public.pem"
- With all these files in place, run a backup job:
# proxmox-backup-client backup etc.pxar:/etcThe key will be stored in your backup, under the name
rsa-encrypted.key.Note
The
--keyfileparameter can be excluded, if the encryption key is in the default path. If you specified another path upon creation, you must pass the--keyfileparameter. - To test that everything worked, you can restore the key from the backup:
# proxmox-backup-client restore /path/to/backup/ rsa-encrypted.key /path/to/targetNote
You should not need an encryption key to extract this file. However, if a key exists at the default location (
~/.config/proxmox-backup/encryption-key.json) the program will prompt you for an encryption key password. Simply movingencryption-key.jsonout of this directory will fix this issue. - Then, use the previously generated master key to decrypt the file:
# proxmox-backup-client key import-with-master-key /path/to/target --master-keyfile /path/to/master-private.pem --encrypted-keyfile /path/to/rsa-encrypted.key Master Key Password: ****** New Password: ****** Verify Password: ******
- The target file will now contain the encryption key information in plain text. The success of this can be confirmed by passing the resulting
jsonfile, with the--keyfileparameter, when decrypting files from the backup.
Warning
Without their key, backed up files will be inaccessible. Thus, you should keep keys ordered and in a place that is separate from the contents being backed up. It can happen, for example, that you back up an entire system, using a key on that system. If the system then becomes inaccessible for any reason and needs to be restored, this will not be possible, as the encryption key will be lost along with the broken system.
It is recommended that you keep your master key safe, but easily accessible, in order for quick disaster recovery. For this reason, the best place to store it is in your password manager, where it is immediately recoverable. As a backup to this, you should also save the key to a USB drive and store that in a secure place. This way, it is detached from any system, but is still easy to recover from, in case of emergency. Finally, in preparation for the worst case scenario, you should also consider keeping a paper copy of your master key locked away in a safe place. The paperkey subcommand can be used to create a QR encoded version of your master key. The following command sends the output of the paperkey command to a text file, for easy printing.
proxmox-backup-client key paperkey --output-format text > qrkey.txt
#####
Ich hatte es bereits mit den jüngeren Versionen von PBS probiert, aber nie Erfolg gehabt. Mit der aktuellen Version von PVE 7.0.8 und PBS 2.0.4 funktioniert es endlich.
Ziel: möglichst schnelles Restore eines ausgefallenen PVE-Hosts über den Proxmox Backup Server.Voraussetzung: Normal ist die Benutzung von BTRFS und ZFS für die Spiegelung der Installation vom PVE sehr sinnvoll.
--> für Sicherung und Desaster Recovery des PVE-Hosts mit SW-RAID BTRFS oder ZFS über PBS findet ihr unten im weiteren Post die entsprechenden Hinweise
Wir wissen, dass der PBS erst zu 60% fertig ist und noch wachsen WIRD. Das ist nun mal der normale Lauf.
Meine Lösung hier setzt ein Blockdevice zur Installation voraus - sinnvoller Weise ein HW-Raid1. Da man hier keinen Bitrotate-Schutz hat, sollte man in Produktionsumgebungen Enterprise-Class-HDDs verwenden.
Beim Restore kann der Backup-Client leider noch nicht direkt auf das Blockdevice zurück sichern, deshalb gehen wir einen kleinen "Umweg". [bzw. siehe Ergänzungspost]
Leider habe ich diese Lösung nicht mit einem PVE-Host im Cluster probiert, da ich vermute, dass die Clusterkonfiguration dann nicht mehr mit den anderen Hosts harmoniert. Bei Windows wäre das auf jeden Fall so ;-). Man muss diese bestimmt manuell korrigieren, indem man den Host temporär aus dem Cluster entfernt und dann wieder integriert, könnte ich mir vorstellen. Es sei aber jeder ermutigt, dies mal nachzustellen und hier zu berichten.
Sicherung kann im Livebetrieb dann inkrementell passieren.
- # proxmox-backup-client backup pve_sda.img:/dev/sda --repository 192.168.122.3:bkpstorage --backup-type host --crypt-mode none
-> dies vollführt eine Image-Sicherung (nicht konsistent) vom Blockdevice sda auf den PBS
- das Blockdevice steht sinnbildlich für das HW-RAid und enthält dann alle Partition, LVM-Volumes, Bootmaster und Co
Wiederherstellen
0. man startet nun den PVE-Host von einer Live CD - am besten Debian - bei mir war es eine Version 10
[zusätzlich steckt man ein Laufwerk hinzu (zB USB), das größer ist als dein Boot-Blockdevice im Host]
1. Installieren des Backup-Clients
Debian 10:
# sudo apt install wget
# sudo wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
- in source.list einfügen:
- dann
#sudo apt update und client installieren
# apt-get install proxmox-backup-client
2. Sicherung temporär zurückspielen (kleiner Umweg)
- die zusätzliche Platte formatieren und einhängen (bei mir unter /mnt)
- jetzt Restore der Sicherung in eine temporäre Datei (pve_root.img) auf dieser Zusatzplatte
# proxmox-backup-client restore host/pve/2021-07-26T20:52:27Z pve_sda.img /mnt/pve_root.img --repository 192.168.122.3:bkpstorage
3. nun temporäre Imagedatei auf Blockdevice übertragen
# dd if=/mnt/pve_root.img of=/dev/sda bs=4096
Fertig
- nach Reboot ist der alte Host wieder online
Vorteile dieser Lösung:
- ich kann im Livebetrieb regelmäßig sichern
- nur wenige Schritte zum kompletten Restore - keine Neuinstallation wie bei einer File-Restore Lösung
- man hat Boot Medium für Desaster Recovery
- PBS wird auch als Backupziel für die PVE-Hosts genutzt - keine separate Backupumgebung für Hosts notwendig (wie wenn ich z.B. synology nutzen würde)
fpausp
Well-Known Member
floh8
Active Member
Man kann den Restore doch ohne "Umweg" also ohne Zusatzplatte tätigen, wenn man Linux besser kennt, was ich nicht tue. Proxmox hat nämlich dem Client genehmigt an stdout zu senden. Das erfolgt mit "-", wie in der Doku erwähnt. Der folgende Befehl würde also Punkt 2 und 3 von oben zusammenfassen.
# proxmox-backup-client restore host/pve/2021-07-26T20:52:27Z pve_sda.img - --repository 192.168.122.3:bkpstorage | dd of=/dev/sda bs=4096
Reactions:dafont, Dunuin and DerDanilo
Dunuin
Famous Member
Werde ich die Tage mal testen.
Was mir da vorschweben würde wäre ein USB Stick mit einem persistenten Live Debian 11 drauf. Den müsste ich dann nur einmal einrichten und könnte dann immer von dem booten um meine beiden Boot/Root-SSDs zu sichern bzw im Ernstfall dann auch wiederherzustellen. Da würde dann sicher auch ein Bash-Script Sinn machen, was dann nach dem Boot per Autostart mitgestartet wird und einen dann fragt ob man ein Backup sichern oder wiederherstellen will. Wenn man es richtig gut machen will könnte man auch noch eine Menüführung einbauen welche...
1.) einem vor dem Sichern fragt welche Laufwerke man sichern will. Hier könnte man dann eine Tabelle mit sdX, UUID, Modell und Größe angezeigt bekommen. Und das zuletzt gewählte könne man dann in einer Konfig-Datei per UUID speichern, damit sich das Script das zuletzt gewählte merken kann und man es nicht für jede Sicherung neu wählen muss.
2.) einem vor dem Restore eine Liste mit allen Backups anzeigt und dann ein entsprechendes Backup wählen lässt. Danach eine Liste mit allen verfügbaren Images des gewählen Backups. Dann wählt man das (einzelne) gewünschte Image und danach wählt man das Ziellaufwerk.
3.) es einem erlaubt den Server automatisch nach dem erfolgreichen Backup zu rebooten, damit man wieder in PVE landet
Das wäre dann wirklich super praktisch. Da würde ich den USB Stick dann einfach immer gesteckt lassen. Und steht dann mal wieder ein PVE update an, starte ich kurz im Browser das WebKVM vom IPMI, reboote den Server, Drücke F12 oder was das war um statt von den SSDs vom USB-Stick zu booten. Dann bin ich automatisch im Backup-Script, kann mit 2 Klicks kurz ein Sichern veranlassen und muss dann nur rebooten und bin wieder normal im PVE. Und dann kann ich normal mein PVE updaten ohne groß Sorgen haben zu müssen, dass da das Update etwas zerschießt.
Weil mein PVE ist schon etwas komplizierter und da steckt viel Arbeit (bestimmt 100+ Stunden) drin. Da kann ich nicht mal schnell ein neues PVE aufsetzen wenn etwas kaputt gehen sollte.
Aber bist du sicher, dass das mit dem Blocklevel Backup im laufenden Betrieb wirklich klappt? Normalerweise wird ja davon abgeraten z.B. ein fsck, Partitionierung etc auf einem Laufwerk durchzuführen, welches noch gemountet und in Benutzung ist. Und selbst auf Dateiebene möchte man ja normal nicht einfach im laufenden Betrieb ein Backup machen sondern vorher ein Snapshot erstellen und dann das Backup auf Basis des Snapshots erstellen.
floh8
Active Member
ich betrachte hierbei mal nicht mdadm-Raids, weil die aus meiner Sicht nicht mehr Stand der Technik für System-Raids sind, und btrfs, weil wir noch nicht wissen, wie sich die Konfiguration bei Proxmox weiter entwickelt. Es ist ja nur experimentell gelabelt. Somit habe ich den Wink von @Dunuin mal aufgegriffen und mir nochmal Gedanken zum zfs als Rootfilesystem gemacht.
Man kann natürlich eine Offline-Sicherung beider Platten machen. Dies habe ich mal getestet und keine Probleme festgestellt. Somit kann ich eine Offline-Sicherung eines zfs-Systems sehr gut als Rollback verwenden, wenn ich Systemupdates fahre. Herunterfahren kann ich den Host ja ohne Probleme, da zu so einer Wartung keine aktiven Container oder VMs laufen.
Für die alltäglichen Konfigurationsänderungen reicht dies natürlich nicht aus, weil ich das System vor der Änderung herunterfahren muss. In meinem Thread zu zfs/btrfs stelle ich die Snapshot-Funktion als sehr nützlich raus. Nachteil ist trotzdem, ich muss das System für ein Rollback neu booten. Wenn ich ein DR-Fall habe, nützt mir nur ein aktuelles Offline-Backup, Snapshot alleine nützt nichts. D.h. im Endefffekt hat jede Sicherungsvariante, von der man hier im Forum liest, ihre Berechtigung.Folgende Varianten sehe ich:
|
Backup-Typ
|
Erstellen
|
Nutzen
|
Restore
|
| zfs snapshot | online | Systemupdate, Konfigurationsänderungen | offline, Live-CD |
| Voll-Image HDD1/2 auf PBS | offline | DR, Systemupdate | offline, Live-CD |
| Image Part1/2,MBR auf PBS | online | DR, Systemupdate | offline, Live-CD |
| Filebased auf PBS | online | DR, Konfigurationsänderung | online+offline |
Für die optimale Installation eines PVE würde ich also Folgendes nutzen:
1. System mit zfs installieren
2. folgende Backupvarianten stehen zur Auswahl
Jeder muss halt selber entscheiden, was für ihn besser ist. Nochmal gegenüber gestellt.
|
Eigentschaften
|
Variante 1
|
Variante 2
|
| Sicherungen | 1) zfs snapshot + 2) Image v. Part1/2,MBR(2x) + 3) Filebased |
1) Voll-Image (2x) + 2) Filebased |
| Zeitaufwand Sicherung | viel geringer | normal |
| Zeitaufwand Rollback | viel geringer | normal |
| Sicherung online | ja, alle Sicherungen | nur Filebased |
| Rollback online | nein | nein |
| DR Tasks | 1) Neuinstallation von ISO + 2) Restore Image Part1/2 (2x) + 3) Restore filebased |
1) Restore Voll-Image v. hdd1/2 + 2) Restore Filebased |
| DR Zeitaufwand | gleich | gleich |
| Singel File Restore | ja | ja |
Nüchtern betrachtet wäre Variante 1 viel effizienter, weil ich die Sicherungen alle online machen kann.
Den MBR benötige ich eigentlich nicht, weil ich für das DR sowieso von ISO installieren muss. Er muß theoretisch auch nur am Anfang einmal gesichert werden, weil er sich nie ändert. Mit meiner Filebased-Sicherung kann ich individuelle Restores einer Datei anschieben. Wenn ich mir also ein Verzeichnis /backup anlege und dort ein dd-image vom MBR reinlege, könnte ich dieses individuell über die filebased-Sicherung wiederherstellen. Für Partitionen 1 und 2 arbeitet der backup-client auch in Kombination. Man könnte also für eine Komplettsicherung auch verwenden:
# proxmox-backup-client backup pve_sda1.img:/dev/sda1 pve_sda2.img:/dev/sda2 ......pve_sda1.img:/dev/sda1 pve_sda2.img:/dev/sda2 pve_root.pxar:/ --repository 192.168.122.4:bkpdatastore2 --backup-type host --crypt-mode none
Kurzübersicht:
Sicherung vor einem Systemupdate:
1. zfs snapshot
Sicherung nach einem Systemupdate (=Vollisicherung für DR):
[1. ] # dd if=/dev/sda of=/backup/mbr_sda.img bs=512 count=1
# dd if=/dev/sdb of=/backup/mbr_sdb.img bs=512 count=1
2. # proxmox-backup-client backup pve_sda1.img:/dev/sda1 pve_sda2.img:/dev/sda2 pve_sdb1.img:/dev/sdb1 pve_sdb2.img:/dev/sdb2 pve_root.pxar:/ --repository 192.168.122.4:bkpdatastore2 --backup-type host --crypt-mode none
floh8
Active Member
Das wäre natürlich eine klasse Sache so ein Script. Das könntest du dann an Proxmox verkaufen, damit es im PBS Debug-Modus nutzbar ist.
Du beziehst dich sicherlich auf eine Plattenkonfig. Die könnte der proxmox-client halt online nicht mit sichern.
Na, ich habs ja getestet. Gut meine Daten waren nicht kompliziert. Proxmox hat nichts anderes umgesetzt als andere Anbieter auch. Denke mal an Veeam. Da kannst du auch ein gemountetes System konsistent sichern oder das Project rear, dass sehr viele Provider einsetzen. Sehr beliebt. Das läuft auch online. Es sind keine konsistenten Backups. Ich fand einen Hinweis hier im Forumsportal, dass eine Sicherung im laufenden Betrieb vom proxmox-backup-client nicht konsistent ist. Für den Host ist es aus meiner Sicht nicht so schlimm, denn hier laufen keine DBs oder ähnliche Apss, die sowas benötigen. Ich habe es oben hinzugefügt. Wenn es doch Probleme geben sollte, könnte man die Dienste vorher anhalten.
Dunuin
Famous Member
Ich habe da ziemlich viel am Host geändert...
- Ist ein Debian 10 mit PVE oben drauf und nicht einfach die PVE ISO
- ist Systemvollverschlüsselung
- initramfs-dropbear (angepasst für VLAN support + eigenem unlock Script) statt dem normalen initramfs damit ich root/swap per SSH Passworteingabe entschlüsseln kann
- SWAP, boot und root Partitionen als mdadm raid1 weil man von einem verschlüsselten ZFS nicht booten konnte (geht wohl seit OpenZFS 0.85 inzwischen)
- Zabbix Agent mit etlichen individualisierten templates und Scripts die z.B. über smartctl die Laufwerksdaten, ZFS Statistiken etc mitloggen
- Filebeat um meine Logs an Graylog zu senden
- eigenes Script was per ipmitool meine Hardware überwacht und die Lüfter regelt
- eigenes Script zum Entschlüsseln und Mounten meiner ZFS und LVMthin VM Storages sowie starten meiner VMs
- ziemlich aufwändige Netzwerk-Konfiguration mit 7 NICs, 13 VLANs, 14 Bridges, massig Firewall-Regeln, ...
- etliche nachinstallierte Programme zum Flashen von Firmwares etc, ZED, ipmitool, Skripte für automatische Snapshotverwaltung, ...
- Installation von Postfix als Email-Server
- Einrichtung von NUT für geregeltes Shutdown bei Stromausfall
- selbstgeschriebene systemd Scripts
- Anpassung von etlichen Konfigdateien wie ksmtuned, zfs, sysconf, sshd, crontab, fstab
- Einrichtung von etlichen PAM Usern/Gruppen, Einrichtung von sudo, Erstellen von neuen Rollen für PVE
- direktes einbinden verschiedenster SMB/NFS Shares über fstab
- Konfiguration von Backups
- verschiedenste Ordner wie /tmp auf RAM-Disks auslagern
- Einrichten von IOMMU-Support für NIC/GPU passthrough
- standby für HDDs über hdparm verbieten
- Anpassung des Intel_Pstate Governors für bessere Energieeffizienz
- ...
Das wäre schon super nervig wenn ich alles neu machen müsste...
Also für mein Windows habe ich noch kein Backup-Tool gefunden was im laufenden Betrieb läuft und wirklich alles sichern kann ohne dabei früher oder später abzubrechen. Normalerweise arbeiten die Backup-Tools wie UrBackup etc ja so, dass diese Shadowcopy benutzten um quasi ein Snapshot vom NTFS anzulegen und basierend dadrauf machen die dann ihre Backups. Weil alle meine SSDs aber mit Veracrypt verschlüsselt sind kann Windows kein Shadowcopy mehr benutzen und das hat dann zur Folge, dass da kein Backup-Programm in der Lage ist irgendwelche Dateien zu sichern welche gerade geöffnet sind und benutzt werden. Gerade auf C sind dann immer irgendwelche Systemdateien die sich einfach nicht sichern lassen wollen. Das macht dann inkrementelle Backups nicht nutzbar, da ja nie wirklich alles gesichert werden kann und jedes Backup dann unvollständig ist. Das beste was ich da bisher gefunden habe ist einfach alles per rsync auf mein NAS zu schieben und weil es keine Versionierung gibt werden dann halt alle Backupversuche kombiniert und man erhält einen Brei aus Daten der relativ vollständig sein sollte, wovon aber alle Dateien unterschiedlich aktuell sind. Versionierung erhalte ich dann weil unten drunter ZFS mit Snapshots läuft. Aber ist halt schon ziemlich unschön das Ganze.
floh8
Active Member
Ja, wenn man mit Verschlüsselung arbeitet, dann ist man beim Backupen schon ganz schön eingeschränkt - keine Frage. Diesbezüglich habe ich wenig Erfahrung. Mit 'ner individuellen Installation + Verschlüsselung ist die Offline-Variante wohl der simpelste Weg, denke ich.
Für deine Clients könnte dich ja https://www.askwoody.com/forums/topic/veracrypt-and-backup/ interessieren.
Dunuin
Famous Member
Ja, wenn dann auch richtig.
Am liebsten würde ich hier daheim ja einen HA Cluster mit CEPH aus 3 Nodes betreiben, aber das gibt leider das Budget und die Stromrechnung nicht mehr her um mir noch einen 4ten und 5ten Heimserver anzuschaffen
Dunuin
Famous Member
Wie sage ich dem backup-client unter welcher "group" die Backups gespeichert werden sollen?Du gibst da nur "
# proxmox-backup-client backup pve_sda.img:/dev/sda --repository 192.168.122.3:bkpstorage --backup-type host --crypt-mode none" beim erstellen an, wenn ich mir aber dein Restore Befehl angucke (proxmox-backup-client restore host/pve/2021-07-26T20:52:27Z pve_sda.img ...), dann landen die Backups unter der Gruppe "pve" auf dem PBS. Host gibt man mit "--backup-type host" an, aber in der Doku konnte ich weder einen Befehl finden, um die Gruppe manuell festzulegen, noch konnte ich entnehmen, woher der backup-client die Info dann beziehen sollte.
floh8
Active Member
für individuelle manuelle aufrufe gibt es noch "--backup-id {bezeichnung}" als parameter.