A lot of time restauring VM backups

[LkS45]

Hey guys!



Well, from the "progress 100% read..." to "total bytes read..." i got more that 2h! And the vm backup is only 150gb;
Well, that is, it takes more or less the same time from 1% to 100% as it does for the "task ok" message.
The whole process took a total of 4 hours, with 2 hours from 1 to 100% and another 2 hours for "task ok".
I have this problem with all my servers on my cluster. No any error message only the "no such logical volume pve/data".

Thanks.

 

[LkS45]

and? only one hdd and 2 core intel lga 775 CPU? or what?

My question is: why does the task take another two hours to finish after reaching 100% completion?
Since theoretically it should finish when it reaches 100%.

 

[leesteken]

IIRC, Proxmox waits for the writes to actually be written to the drive (fsync, flush, that kind of thing), when it's between progress 100% and total bytes. Sounds like half of the data is still in memory if that takes as long as getting to a 100%. Note that the percentage is about reads and not writes.
What make and model is the destination drive? Is it a SSD with QLC flash memory or is it a SMR HDD maybe?

 

[Kingneutron]

You're not providing ANY pertinent information here. What disk(s) are you using on source (backup) and destination (restore)? Are you restoring to a RAIDZ or what?

Gig ethernet? Faster?

No such volume pve/data means you probably tried to restore it to the wrong place, it's looking for lvm-thin on your destination and not finding it. Was probably stored with the backup. The storage has to exist on the Restore node, or you need to change the destination storage in the dropdown before actually restoring

If you want fast(er) restores, you should be backing up to PBS on SSD / nvme and restoring over at least 2.5Gbit

 

[LkS45]

You're not providing ANY pertinent information here. What disk(s) are you using on source (backup) and destination (restore)? Are you restoring to a RAIDZ or what?

Gig ethernet? Faster?

No such volume pve/data means you probably tried to restore it to the wrong place, it's looking for lvm-thin on your destination and not finding it. Was probably stored with the backup. The storage has to exist on the Restore node, or you need to change the destination storage in the dropdown before actually restoring

If you want fast(er) restores, you should be backing up to PBS on SSD / nvme and restoring over at least 2.5Gbit

My question is simple: I asked if it's normal for a backup restore task to take hours and hours when it reaches 100%, or if it should finish immediately after reaching 100%.
In any case, the server uses SSD disks with the ZFS file system.

 

[Johannes S]

My question is simple: I asked if it's normal for a backup restore task to take hours and hours when it reaches 100%, or if it should finish immediately after reaching 100%.

And this depends (beside other things) on your network setup (GBit/s, available bandwith, other workloads) and the amount of data to restore.

Let's say you have a bandwith of 1MB/s (obviouvsly unrealistically low) then I i would expect a very long restore time. On 100G or 25G network I would expect the opposite. And it makes a difference whether the restore needs to restore a very small VM (around 1GB) or 1TB (e.G. a fileserver). Your post is missing a lot of needed information.

But if you just want an answer: For me restores never take such a long time although my home network is quite slow (1Gbit/s) but my VMs are also not very large. I doubt however that this answer will help you