I’m using Proxmox with Ceph. Is using rbd export the same with running Proxmox backup? The rbd export is faster from what I can tell but not sure if there is any impact to the running VM.
Backup vs RBD Export
- Thread starter tinduong1337
- Start date
No, it's not the same. Backup of the VM has the configuration backed up as well as the disk, but maybe you don't care about that, or may be backing that up on your own? And of course, you get all the disks, rather than just one...
Then, as for the disk, if the VM is running, the same stuff applies here as a direct disk copy: you won't see what's in the buffers, and you may not get a reliable backup of live filesystem jokers (think remote FS, databases…).
So your backup might be a bit unreliable, or unusable at all. Proxmox backup uses qemu to help making sure the backup is nicely done, and has all the wanted data (you can also capture RAM…). You can add some interaction in the guest, by responding to freeze/thaw events for annoying usual suspects. I suspect you could plug yourself in qemu to get all that and do your backup using rdb export if it's significantly faster, it could be useful.
Maybe a cool patch to write for vzdump there, using that for Ceph-backed disks.. I think the regular backup work nicely though, so I'm not too excited by such a thing
Cheers,
Gilou
Then, as for the disk, if the VM is running, the same stuff applies here as a direct disk copy: you won't see what's in the buffers, and you may not get a reliable backup of live filesystem jokers (think remote FS, databases…).
So your backup might be a bit unreliable, or unusable at all. Proxmox backup uses qemu to help making sure the backup is nicely done, and has all the wanted data (you can also capture RAM…). You can add some interaction in the guest, by responding to freeze/thaw events for annoying usual suspects. I suspect you could plug yourself in qemu to get all that and do your backup using rdb export if it's significantly faster, it could be useful.
Maybe a cool patch to write for vzdump there, using that for Ceph-backed disks.. I think the regular backup work nicely though, so I'm not too excited by such a thing
Cheers,
Gilou
Thank you for your response.No, it's not the same. Backup of the VM has the configuration backed up as well as the disk, but maybe you don't care about that, or may be backing that up on your own? And of course, you get all the disks, rather than just one...
Then, as for the disk, if the VM is running, the same stuff applies here as a direct disk copy: you won't see what's in the buffers, and you may not get a reliable backup of live filesystem jokers (think remote FS, databases…).
So your backup might be a bit unreliable, or unusable at all. Proxmox backup uses qemu to help making sure the backup is nicely done, and has all the wanted data (you can also capture RAM…). You can add some interaction in the guest, by responding to freeze/thaw events for annoying usual suspects. I suspect you could plug yourself in qemu to get all that and do your backup using rdb export if it's significantly faster, it could be useful.
Maybe a cool patch to write for vzdump there, using that for Ceph-backed disks.. I think the regular backup work nicely though, so I'm not too excited by such a thing
Cheers,
Gilou
The reason behind my question is that I want to obtain the raw dump of the disks instead of a VMA file. I’m aware that the CLI can be used to convert or export the backup, but I was wondering if there’s a more direct way to achieve this.
there is another factor. using vzdump issues a qm freeze before backup; using an uncontrolled rbd snap does not.
qm freeze is not helpful in our case, as it actually makes the VM running cPanel to hang
https://forum.proxmox.com/threads/pve-cpanel-vm-freeze.112528/
Understand what is actually happening. If you are NOT able to issue a qm freeze, it means that ALL WRITES IN FLIGHT will be ignored for the purposes of backup. any data in buffer will not be written out, leaving all those affected files open. your backups will contain corrupt data.
I understand that, but it's not an option to enable qm freeze with VM running cPanel and CloudLinux - https://forum.proxmox.com/threads/backup-scheduler-stop-every-day-the-vm.103539/page-3
I guess the complete question is, without qm freeze and not taking vm configs into account, is running backup from Proxmox the same with rbd export?
We do it in production, here our in house scripts https://github.com/JackSlateur/backurne.git
@spirit this is pretty nice! I dont know if this covers the same ground, but are you experiencing the issues @tinduong1337 was mentioning? I see you do issue a qm-freeze (which is proper and sane)
Is there anything classy you guys don't do hahah! That is impressive, I think one of you mentioned it @ FOSDEM now that I think of it..
Well, without qm freeze, you could miss some datas in memory buffer. But no corruption, as your filesystem is doing fsync and barrier. Also, Its help if you have application use multiples disks. (Like a bdd with transactions logs on différent disks ). We dont have implement yet Ceph rbd group Snapshot
that's awesome! thanks @spirit the `map` command is really useful. is there any way we can map it directly to the running VM?
OOC, are you running HDD Ceph cluster for backup?
ah, currently no, because we don't have to give access to backup storage to the vm.
But you could try to script something, doing a reverse ssh tunnel and mounting through nfs/smb , don't known ^_^.
Currently your workflow is to restore from the backup storage to the vm through ssh copy.
I’m curious about your configuration for the HDD cluster, if you’re open to sharing. Specifically, details like the number of nodes, disk sizes, number of disks per node, number of OSDs per disk, SSD caching, performance, and any other relevant setup details would be really helpful.
I’ve been working with NVMe clusters so far, but this will be my first time deploying an HDD-based cluster. It would be great to have some references to use as a baseline!