Network/Roadmap/RebuildBackupServer: Difference between revisions

From NURDspace
No edit summary
No edit summary
 
(7 intermediate revisions by 2 users not shown)
Line 2: Line 2:
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.
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 =
= Architecture =
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.
We are going to use proxmox-backup as our backup solution. This means that all systems need to have the proxmox backup client. <s>For systems that cannot run this client (eg, arm devices), we need to have an in-between system which does have the client.</s>
 
There is an ARM solution https://github.com/ayufan/pve-backup-server-dockerfiles
 
= Steps =
* <s>Install PBS</s>
* <s>Configure Erratic to backup to PBS</s>
* Run a initial backup on Erratic & verify backups
* Setup Proxmox Backup Client on X86 systems
* Setup Proxmox Backup Client on ARM systems
 
The last two steps could possibly be automated with Ansible.
 
 
'''Some caveats:'''
* Some of our systems are running Ubuntu
* Spacesound is running Fedora


= 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 =
'''Notes:'''
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)
* Make it use the community repo https://geekistheway.com/2021/03/06/how-to-setup-proxmox-backup-server-pbs-community-repository/
* Disks added to VM using
qm set 137 -scsi1 /dev/disk/by-id/ata-TOSHIBA_MD04ACA400_761AKLZCFSAA
qm set 137 -scsi2 /dev/disk/by-id/ata-TOSHIBA_MD04ACA400_761DKTFUFSAA
 
= Configuration =  
PBS is configured with two drives directly passthrough to the VM. From there we have a ZFS mirror.
 
Erratic has PBS configured as a backup volume under the root Erratic (backups/erratic) with it's own user. This is so that we can keep backups separated on a per device basis
 
A monthly cron has been configured that verifies the entire dataset.

Latest revision as of 15:06, 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.

There is an ARM solution https://github.com/ayufan/pve-backup-server-dockerfiles

Steps

  • Install PBS
  • Configure Erratic to backup to PBS
  • Run a initial backup on Erratic & verify backups
  • Setup Proxmox Backup Client on X86 systems
  • Setup Proxmox Backup Client on ARM systems

The last two steps could possibly be automated with Ansible.


Some caveats:

  • Some of our systems are running Ubuntu
  • Spacesound is running Fedora


Notes:

qm set 137 -scsi1 /dev/disk/by-id/ata-TOSHIBA_MD04ACA400_761AKLZCFSAA
qm set 137 -scsi2 /dev/disk/by-id/ata-TOSHIBA_MD04ACA400_761DKTFUFSAA

Configuration

PBS is configured with two drives directly passthrough to the VM. From there we have a ZFS mirror.

Erratic has PBS configured as a backup volume under the root Erratic (backups/erratic) with it's own user. This is so that we can keep backups separated on a per device basis

A monthly cron has been configured that verifies the entire dataset.