Best practice for Proxmox self-backup

Ulf .. due to the above command I noticed that there was a mismatch in the script's backup path and the path I entered in to the crontab. Further testing showed that the only line I needed to add in the crontab was this one:

TERM=xterm

So the path is backup taken correctly from the script and sh vs. bash is not the problem.

My final crontab looks like this:

TERM=xterm
14 1 * * * /usr/bin/curl -I http://192.168.xx.xx:80 >/dev/null 2>&1
15 1 * * * /bin/echo | /prox_config_backup.sh >/dev/null 2>&1
16 1 * * * /usr/bin/find /mnt/nas/_system -type f -mtime +7 -exec rm {} + >/dev/null 2>&1

Thanks for taking your time .. your help is much appreciated!
 
Last edited:
as an earlier post suggested - rsnapshot is a superb tool for backing up pve host.

we've used it since it was written on all systems to backup locally and remote.

from the man page
Code: 
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.

we use rsnapshot to backup systems and data. it is a great backup tool.
 
RobFantini said:
we use rsnapshot to backup systems and data. it is a great backup tool.
Click to expand...

You are welcome to submit your rsnapshot backup code as pull request.
Maybe it's even better to provide it as an alternative tool than using only utilities that are available on default.
 
DerDanilo said:
Maybe it's even better to provide it as an alternative tool than using only utilities that are available on default.
Click to expand...

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.
 
Last edited:
Hellpo Guletz .

here is what we backup using rsnapshot. Is there anything else that you include?

This is for local backup . We also do remote pulls.
Code: 
backup  /etc/                           localhost/
backup  /etc/pve/                       localhost/
backup  /var/lib/pve-cluster/           localhost/
backup  /root/.ssh/                     localhost/
backup  /usr/local/bin/                 localhost/
 
Hi,

I also use this(and include yours):

/var/lib/pve-firewall
/var/lib/pve-manager
/var/lib/pve-zsync
/var/lib/lxc
/var/spool/cron
/root
/boot
 
guletz said:
Hi,

I also use this(and include yours):

/var/lib/pve-firewall
/var/lib/pve-manager
/var/lib/pve-zsync
/var/lib/lxc
/var/spool/cron
/root
/boot
Click to expand...

Thank you for that .

I added all of those to our off node backup - we use a large lxc named rsnapshot on nfs .

for local backups - those go to /rsnapshot , added all except /boot as there are sometimes storage space limitations.
 
Very interesting thread, look forward to testing this out. The limited backup abilities have always made me nervous to the point where I have been manually creating images of the PVE boot SSD just in case.

That said, can anyone shine some light on what to do if you needed to restore from a backup? Is there a way of testing restores?

Also, what about tools like Veeam Agent for Linux - would that work with Proxmox?
 
DerDanilo said:
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.
Click to expand...
Hello,
i search about that,but there is no luck so how to do it.
thanks
 
Hi,

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


Good luck.
 
  • Like
Reactions: Zaman and DerDanilo
If i were to add to this discussion, i personally think it's not the most appropriate way to address the Proxmox backup. I'd separate the backup part into 2 aspects:
  1. backing up the configs (storage, cluster, network, VMs, containers, backup cron)
  2. restoring the OS
I see that the optimal approach is the following:
  1. for configs - simply have them somewhere offsite. Here's what you need to back up: https://pve.proxmox.com/wiki/Bypassing_backup_and_restore_when_upgrading
  2. for the OS - i think that any enterprise should aim to have a deployment script that would get the machine up and running within 2-3 minutes
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.
 
  • Like
Reactions: Zaman, guletz and DerDanilo
Vladimir Bulgaru said:
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.
Click to expand...

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?)
 
guletz said:
Hi,

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


Good luck.
Click to expand...
first: thanks
second:
Ok,how two connect each other by storage
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back