Proxmox-backup-client restore target question

[lanepark5033]

I restored an img of a single standalone SSD that was backed up to the PBS. When doing the restore to a standalone disk using " - | dd of=/dev/sdx bs=4M status=progress" as the target the restore took 5 hours:-(( It was a 500GB SSD.
Now I want to determine what is the slowdown, the PBS move to the PC or the DD translate and save to the disk. (Its a spare empty disk)
The problem I am struggling with is the target value to replace the DD with. /dev/sdx gives a failure of file already exists if the disk is formated but unmounted.
Question is, how should I prep the taget drive to receive the .img file ? Should it be totally unallocated ? Or should it be allocated but not mounted ? (If allocated it becomes sdx1.....)
Sorry for the newbe question
Regards

 

[UdoB]

The problem I am struggling with is the target value to replace the DD with. /dev/sdx gives a failure of file already exists if the disk is formated

Really? I have never seen "dd" being able to know anything about the to-be-overwritten content of the destination device. The only requirement I see is that the device must be present and writable. Specifically an existing partition table will not stop "dd" to write data over it.

Please post the complete command you used plus the error message you get. Add an overview of your block devices: lsblk -o+FSTYPE,MODEL | grep -v zd. Please use [code]...[/code]-tags for this.

Note that in the Gui the behavior is different: from the PVE Gui you can zap a disk. This mechanism will deny to do it if the device is used somewhere in the Storage stack. (Be it a PV for LVM, an OSD for Ceph or a device for ZFS or just another mounted filesystem, I believe.)

 

[lanepark5033]

Having rethought the issue I've come to relize that the slow "restore" is a function of the 500GB SSD that is the target of the restore. The SSD is a TLC level drive and as sucn has a lower TBW and a relatively small VRAM front end buffer in the neighborhood of 8MB. Once the VRAM fills the upload speed of the drive is limited to the speed of the backend NVRAM storage. While watching the restore process with a nload nic monitor I could see that shortly after starting a restore using the "dd" app as the "target" of restore, the amount of data being received slowed down a LOT.
So no matter what I do with a 500GB image backup of a standalone PC SSD the restore time will always be slow, even if I write zero's to the unused space.
My solution is to purchase an 80GB SSD (Really inexpensive) and eliminate the huge overhang that the 500GB SSD has.
Thanks for responding to my initial post, I should have given the issue more thought before posting and wasting folks time.
Regards
Attached is a ksnip of the command and failure, this info is probably irrelevent now.