Possible to move a backup / group backup / from a datastore to another one?

[Dark26]

Bonjour,

Just to know if it's possible or not.

Dark26

 

[fabian]

could be implemented, but is not atm.

 

[Dark26]

could be implemented, but is not atm.

ok

 

[iGadget]

Just tried to move backups manually (via terminal) from one datastore to another and this works fine. Changes are picked up by the GUI almost instantly. Just make sure both datastores have set their content to 'VZDump backup file' and respect Proxmox' directory structure.

 

[fabian]

that only works if you move all backups+chunks. you can't just move/copy the metadata, since you also need the corresponding chunks..

 

[iGadget]

that only works if you move all backups+chunks. you can't just move/copy the metadata, since you also need the corresponding chunks..

Perhaps it was simple for me because I only had 1 backup for each VM. Are the chunks stored in a different directory? If so, which one?

 

[fabian]

.chunks inside the datastore. they are not grouped by backup group or snapshot, so you can't tell there to which backup(s) they belong. which is why I initially said this feature is not implemented yet, but could be at some point (the .didx/.fidx file contain the info which chunks they reference, so parsing them would allow copying the right chunks to another datastore).

 

[CSKollar]

I would like to do the same but periodically: backup the whole PBS datastore (file level with .chunks dir and all the others) to cloud storage with rclone sync feature weekly or monthly.

It's possible in the idle period (outside the backup/GC/prune/verify window)? Or should I stop the PBS service to do this and start when the sync completed?

 

[fabian]

yes it's possible, if you don't do any prune/forget/GC operations and sync .chunks, indices, .chunks again it should be consistent (you'll backup some chunks that are not yet referenced, but those just take up space without hurting otherwise).

 

[grepler]

If we store the datastore in a zfs dataset, then all the zfs send/receive replication goodness should apply, right @fabian ?
So if we wanted to do a backup to a dumb (non-PBS) server, we could replicate the dataset and it would have everything we need for a worst-case restore?
Worst case scenario:
If the worst happened and we lost a cluster completely, we install a new copy of PBS, send/receive the dataset to the PBS, configure a new datastore on the new PBS pointing to the ZFS dataset and start restoring systems to a new PVE cluster, right?

 

[fabian]

if you have the datastore contents including the .chunks directory, as well as (copies of) the encryption keys used by the clients in case of encrypted backups, you can easily setup a new PBS instance and use that to access your backups. how you copy datastore to another location is up to you - the usual caveats apply (e.g., a simple rsync copy will only be consistent if you don't have any activity on the datastore, a zfs snapshot + send/recv will be consistent for that point in time, etc.pp.)

 

[grepler]

Wonderful, exactly as I expected. That said, you might mention this kind of restore scenario in your documentation, since it's the kind of thing potential backup users will be concerned about and I don't see it explicitly mentioned.
Love PVE, now love PBS, thanks so much @fabian!