Restore backup of mount points on the original storage

[omgs]

Hi. I use Proxmox 4.4-13/7ea56165 (updated yesterday) on Debian Jessie. I have the PVE VG defined as LVM storage and a thin pool storage for the root disk of containers. I have some mount points with big data separated from the root disk, all of these on PVE. I choose to backup some of these mount points by checking the backup option in the mount point. Then, to test the behaviour in case of restore, I'm offered just one storage, and ALL the mount points are recreated on this choosen storage.
Is there anyway to restore the mount points on the source storage?

 

[LnxBil]

This was discussed on the forum before and IIRC there is currently no way to restore to different storages. You have to move the disks after the restore.

This is due to the fact that the storage information is IMHO not stored in the backup, only the data and the metadata without the used storage. I'm not sure if this is still correct so please correct me if I'm wrong.

 

[dietmar]

See https://pve.proxmox.com/wiki/Linux_Container#_backup_and_restore

You can configure an arbitrary number of mount points with the restore command, so there is no need to move data afterwards.

 

[LnxBil]

Oh, I missed that he asked about the container. For KVM my answer is still correct, isn't it?

 

[dietmar]

Oh, I missed that he asked about the container. For KVM my answer is still correct, isn't it?

Yes, VMs are different.

 

[omgs]

See https://pve.proxmox.com/wiki/Linux_Container#_backup_and_restore

You can configure an arbitrary number of mount points with the restore command, so there is no need to move data afterwards.

Thanks for your reply. Anyway, I think it's perfectly possible, taking that the original mp info is kept, to provide a way to "respect" those settings. I guess that the current behaviour is parsing the settings to see the mps and restore them all, but this parsing "forgets" to watch the associated storage to even try to keep it as it was when the backup was done, falling back to the same storage as the rootfs.

Though it's possible to define extra manual options for this in pct restore, I guess that those who do so, they just try to mimic the stored settings not taken into account (at least that's my case at the moment). Apart from the "nuisance" itself, it's error prone, so I can't think about anything that spoils to develop this idea for future feature.

TIA

 

[dietmar]

If you do not specify any storage the original mp info is used, but allocate on local storage. It is planned to add further storage mapping options in future.

 

[omgs]

If you do not specify any storage the original mp info is used, but allocate on local storage. It is planned to add further storage mapping options in future.

Well, I didn't test the command line, but the Proxmox UI. If you mean that there's a simple way to get a restore taking into account the original storages, then it sounds like it's a feature/bug in the UI, by not allowing the mentioned behavior and forcing everything to go into a specific storage. Is this last is right, what is the way to request this behaviour?

 

[dietmar]

then it sounds like it's a feature/bug in the UI, by not allowing the mentioned behavior and forcing everything to go into a specific storage. Is this last is right, what is the way to request this behaviour?

Fastest way is that you implement it and send a patch ...

 

[omgs]

I've been playing for a while with the command line "pct restore ..." with a test container having a root disk and just one mount point on different storages and I haven't been able to restore the way that I wanted, on a specific storage different from local storage. A command line "pct restore VMID backup.tar.gz" means "--storage local", and just changing the storage just reproduces the initial post conditions. Trying things in mps seem to require the volume to exist previously, which means that pct restore by itself, at this moment, can't just restore to the original storages, and that's not just an UI bug, but something not implemented in the code.

The reason why I asked is I wasn't sure of the status and the features of restoring, together with there was some work in progress and/or demand about this issue. About doing the work myself, I don't have the knowledge to dive into the code, so I'm afraid you can't expect help from me about that. So, I hope someone with the proper knowledge in this forum finds this issue interesting and dedicates the necessary time to implement a solution.

Regards.

 

[dekiesel]

Sorry to dig this up again, but I am in this exact situation.

What is the recommended way of restoring backups if the data on mp1 is bigger than the disk that should hold the restored lv's ?

Restoring to a VG with enough physical disk space and then moving the rootfs of the container to the smaller vg?

 

[Dunuin]

What is the recommended way of restoring backups if the data on mp1 is bigger than the disk that should hold the restored lv's ?

Restoring to a VG with enough physical disk space and then moving the rootfs of the container to the smaller vg?

Yes. No advanced restore options available yet.
If you don't specify a target storage PVE will restore the virtual disks to the different storages that where defined in the config file when the backup was taken. If you want to restore them to different storages (for example because you now got a new host and the old stroages doesn'T exist anymore) you will have to set a new single target storage and PVE will then restore all virtual disks there, so it needs to be big enough to fit all them them and you can then later move the disks around to other storages.