Revision as of 10:43, 2 August 2023

Summary

Our current backup solution is running into limits. We need to rebuild this into something more usable. First decision will be to determine which plan we are going to use for this.

Architecture

We are going to use proxmox-backup as our backup solution. This means that all systems need to have the proxmox backup client. For systems that cannot run this client (eg, arm devices), we need to have an in-between system which does have the client.

@@ Line 1: / Line 1: @@
 = Summary =
 Our current backup solution is running into limits. We need to rebuild this into something more usable. First decision will be to determine which plan we are going to use for this.
-= Plan 1 =
-Rebuild current zfs pool into something more usable. Basically we need to move from a single zfs volume (/backup) for the whole backupset, to a volume per host (/backup/hostname). We also need to rework snapshots into per-host snapshots.
-= Plan 2 =
-Scrap the current design and move to https://www.proxmox.com/en/proxmox-backup-server/overview, since this is also zfs based AND be integrated into our hypervisor. This would mean deleting backup.vm.nurd.space, and repurposing its disks with proxmox-backup-server.
 = Architecture =
-The solution should be lightweight to implement, and all managed systems should automatically become part of the backup process. There needs to be a dedicated server that we can use to dump backups on for devices that cannot use the solution (eg, network devices). System should support snapshots and dedup (if this is not to memory costly)
+We are going to use proxmox-backup as our backup solution. This means that all systems need to have the proxmox backup client. For systems that cannot run this client (eg, arm devices), we need to have an in-between system which does have the client.