Proxmox Backup Server 2.2 erschienen

Die Enterprise Backuplösung, Proxmox, sichert virtuelle Maschinen und Container und stellt sie wenn nötig wieder her. Die Proxmox Backup Lösung integriert sich nahtlos in Proxmox VE. Nun ist die neue Version 2.2 erschienen die einige Fehler behebt und neue Features bringt.

Proxmox Backup Server 2.2 Highlights

• Based on Debian 11.3 „Bullseye“, but using a Linux kernel 5.15, and ZFS 2.1.4;
• Namespace feature: simplify backup management from multiple sources on-premises, remotely, and in the cloud, by organizing backups into „namespaces“ within a single datastore;
• Maintenance Mode with Active Operations Tracking: new “read-only” and “offline” maintenance modes allow for safer maintenance work on a datastore;
• Performance and back-end improvements;
• Support for downloading zstd-compressed tar archives;
• Countless GUI enhancements;
• Press Release Proxmox bringt ‚Namespaces‘ in Proxmox Backup Server 2.2

Proxmox Backup Server 2.2 Release Notes

• Based on Debian Bullseye (11.3)
• Kernel 5.15
• ZFS 2.1.4

Changelog Overview

• Enhancements in the web interface (GUI):
  • Add „Group Filter“ tab to the „Add“ and „Edit“ windows of sync and tape-backup jobs
  • Allow configuration of the default language used in the web interface
  • Add Markdown aware panel for recording structured notes, and support multi-line comments in the node configuration file.
  • Hide RRD chart for IO delay, if no `io_ticks` are returned
  • Improved translations, among others:
    • Arabic
    • French
    • German
    • Japan
    • Polish
    • Turkish
• Datastore Backup Namespaces:
  • Implement backup namespaces for datastores.
  • Add support for syncing a source namespace into any target namespace.
  Namespaces allow for the reuse of a single chunk store deduplication domain for multiple sources, while avoiding naming conflicts and enabling more fine-grained access control.With the max-depth setting, you can control how deep the recursion on finding groups to sync should go.
  • Add support for namespaces in current Proxmox VE 7.2, the following versions form the baseline:
  pve-manager >= 7.2-4, libpve-storage-perl >= 7.2-4, pve-container >= 4.2-1, qemu-server >= 7.2-3, pve-qemu-kvm >= 6.2.0-7
• Maintenance Mode and Active Operations Tracking:
  • Implement read-only and offline maintenance modes for a datastore.
  Track whether each datastore access is a write or read operation, so that Proxmox Backup Server can gracefully enter the respective mode, by allowing conflicting operations that started before the maintenance mode to finish.Once enabled, depending on the mode, new reads and/or writes to the datastore are blocked, allowing an administrator to safely execute maintenance tasks, for example, on the underlying storage.
• General backend improvements:
  • Improve memory footprint
    • Improve interaction with the glibc system allocator to dramatically decrease peak and overall RSS memory usage
    The glibc allocator has a misguided heuristic to detect transient allocations, which will only start to use mmap in allocation sizes above 32 MiB.This means that relatively large allocations end up on the heap, where cleanup and returning memory to the OS is harder to do and easier to be blocked by small, long-living allocations at the top (end) of the heap.By reducing the threshold for switching from the cached heap to the kernel provided mmap to 128 KiB, we can lower peak RSS usage by a factor of 10, or even 20 in some scenarios.See the git commit for more details.
    • Optimize LRU caches
  • Add streaming interfaces for some API endpoints, such as the task-log list or snapshot list.This can remove the need to collect large lists into intermediate memory buffers.
  • Transform all access to group or snapshot lists to efficient, lazy iterators.
  • Improve IO access pattern for some scenarios, like TFA with high user and login count.
  • Disable SSL/TLS renegotiation in the API daemon.
  • For zpools created via the API, set the `relatime=on` flag by default.
  • Allow for the disabling of inode-sorting for chunk iteration.
  While inode-sorting benefits read performance on block devices with higher latency (for example, spinning disks), it also requires extra work to get the metadata needed for sorting, so it’s a trade-off. For setups that have either very slow or very fast metadata IO, the benefits may turn into a net cost.
  • Add dry-run option for the proxmox-backup-client backup CLI command.
  • Verify: Allow one to enforce verification when manually verifying a datastore or namespace through the web interface
  • Improve reload behavior of the proxmox-backup-proxy API daemon
  Close acceptor for new incoming connections immediately on shutdown to avoid connection resets during the wait for running tasks to finish.
• Improvements on file restore
  • Add support for zstd-compressed tar archive download, in addition to the existing zip download option.
  • Add language encoding flag (EFS) to files when creating a zip archive, if an entry is valid UTF-8.
  The tar archive supports more file types (for example, hard links and device nodes), and zstd allows for fast, efficient, and effective compression.This improves the handling of non-ASCII code point extraction under Windows.
  • Allow up to 25s for the file-restore VM to have scanned all possible filesystems in a backup.
  • Improve IO access in the file-restore-for-block-backup VM’s internal driver, and start disk initialization in parallel to staring the API listening task.
  • Avoid automatically pre-mounting ZFS pools.
  On average the restore-tool should be waiting more compared to the previous 12s „worst“ case wait time.The upfront time-cost can be too large to pay initially, for example, if there are many subvolumes present. Thus, only mount on demand.

Quelle: Proxmox Backup Server 2.2 available | Proxmox Support Forum

Proxmox Backup Namespace Funktion

„Namespace“-Funktion vereinfacht Management mehrerer Backup-Quellen – Lokal, Remote und in der
Cloud In Proxmox Backup Server werden Backup-Daten (d.h. Backup-Snapshots und deren referenzierte Chunks) in sogenannten Datastores gespeichert. Zur Verbesserung der Speichernutzung werden Daten
dedupliziert, wobei die Deduplizierung auf der Wiederverwendung von Chunks basiert, welche in den
Indizes in einem Backup-Snapshot referenziert werden. Mehrere Indizes können auf denselben Chunk
verweisen (auch über verschiedene Backup-Snapshots hinweg), wodurch der benötigte Speicherplatz
reduziert wird.
Um Backups übersichtlich zu organisieren und den benötigten Speicherplatz weiter zu minimieren, führt
Proxmox Backup Server 2.2 eine Namespace-Funktion ein. Backups von mehreren Standorten (Remote
oder Lokal) oder Proxmox VE-Setups können nun in ‚Namespaces‘ innerhalb eines einzelnen Datastores
organisiert werden. Da die Deduplizierungs-Technik auf der Ebene des Datastores angewendet wird, wird
so eine optimale Nutzung der Deduplizierung ermöglicht. Weiters wird der Wartungsaufwand reduziert, da weniger Datastores erstellt und verwaltet werden müssen.
Mithilfe von Namespaces können Unternehmen Sicherungskopien von verschiedenen Quellen auf einen
(physischen) Datastore erstellen, wobei zusätzlich eine granularere Zugriffskontrolle zur Verfügung steht
und zudem Namenskonflikte vermieden werden. Die „Namespace“-Funktion ermöglicht die gemeinsame Nutzung eines einzigen Datastores, einschließlich des Chunk-Speichers, über mehrere Backup-IDNamespaces hinweg (z.B. ein Namespace pro Proxmox VE-Cluster).

Proxmox Backup Wartungsmodus mit Taskprüfung

Um Administratoren die sichere Ausführung von Wartungsarbeiten an einem Datastore zu ermöglichen,
wurden die neuen Wartungsmodi „read-only“ und „offline“ hinzugefügt. Zusätzlich prüft Proxmox Backup
Server jetzt auch aktiv laufende Vorgänge, bevor ein Datastore in den Wartungsmodus gewechselt wird.
Dabei werden neue, eingehende Aufträge blockiert, und es wird abgewartet, bis alle mit dem gewünschten Wartungsmodus in Konflikt stehenden Vorgänge abgeschlossen sind, bevor Proxmox Backup Server tatsächlich in den Wartungsmodus wechselt. Ein kürzlich gestarteter Wiederherstellungsauftrag z.B. wird so noch abgearbeitet, das Starten eines neuen Backups jedoch bereits blockiert.