DESCRIPTION rsnapshot is a filesystem snapshot utility. It can take incremental snapshots of local and remote filesystems for any number of machines. Local filesystem snapshots are handled with rsync(1). Secure remote connections are handled with rsync over ssh(1), while anonymous rsync connections simply use an rsync server. Both remote and local transfers depend on rsync. rsnapshot saves much more disk space than you might imagine. The amount of space required is roughly the size of one full backup, plus a copy of each additional file that is changed. rsnapshot makes extensive use of hard links, so if the file doesn't change, the next snapshot is simply a hard link to the exact same file. rsnapshot will typically be invoked as root by a cron job, or series of cron jobs. It is possible, however, to run as any arbitrary user with an alternate configuration file. All important options are specified in a configuration file, which is located by default at /etc/rsnapshot.conf. An alternate file can be specified on the command line. There are also additional options which can be passed on the command line.
In my own oppinion it is far better to use rsnapshot insted of any other backup script, because it have ALL that you need for this task(including: encryption, rsync, ssh, pre/post backup custom scripts, schedule, retention backup policy, hard links for low disk space usag, very well documented) and not least it is rock-solid(I use it for many ...many years on any linux server, and I do not have get any failure when I was need to recover something)!!! And I am very sure that could be easy integrated in PMX.Maybe it's even better to provide it as an alternative tool than using only utilities that are available on default.
backup /etc/ localhost/ backup /etc/pve/ localhost/ backup /var/lib/pve-cluster/ localhost/ backup /root/.ssh/ localhost/ backup /usr/local/bin/ localhost/
Thank you for that .Hi,
I also use this(and include yours):
Hello,With 5.x you can simply add a "backup node" to the cluster who's only purpose is to receive the "backups" via the replication feature (gui). This does not replace offside backups, but does surely narrow the timeframe of lost data in case of a total hardware failure.
Agree. But you can use any HIDS who can check your important OS files. When you need to restore your VM, before go online, you can check it, and the if no checksum is changed then is a good possibility to think that is OK (I know is not 100 % sure, but what it is 100% sure in this days?)The main reason why i think it's a bad idea to restore the OS from a backup is because it addresses only the hardware failure scenario, while ignoring the data corruption and breach scenarios. Therefore restoring the backup without addressing the vulnerabilities creates the false sense of security.
I can guessing what @DerDanilo was trying to say
- you can add a dedicated node or use a existent one only for backup
- this node as the rest of yours node must use zfs as VM/CT storage
- in Proxmox you can use for any VM/CT the replications using as destination this dedicated node