I am testing a vhdz image restore, but receive error that new drive is too small:
“The disk you are trying to restore to is too small. The partition to be restored has size 918.431 GB, but with this disk only 918.431 GB are available.”
These drives are same brand name and size. Must a new drive always be larger? I usually choke a new TB drive down to ~500GB partition to avoid always having a larger drive available as a backup, but these clients came preinstalled. Someday I am going to need a 20TB drive just to restore 50GB of data!
Quite a bit of info there, but I think the important part is:
Imagesize 986157678080
Used bytes 986157678592
Error: Could not write pipe! DownloadImage-3 size 5792 off 0
I see that the restore process is actually creating the partitions (as I expected), but went ahead and used fdisk to delete all partitions and create just one large 1.8TB partition. The restore created its own table with a partition too small. ??
Thanks! Interesting. So it is 511 sectors (each 512 bytes) too short.
It uses Number of sectors * sector size from fsutil fsInfo ntfsInfo C: as volume size. So that would be interesting (but I guess you don’t have it booting?).
Is this somehow related to the vhdz format? I am normally using Raw copy-on-write, but for testing, I put one of these clients in a new group and changed the image format to vhdz in an attempt to make sure I can use this type at a different location (no btrfs there). The image backup appears to go fine, but cannot restore as noted above.
I took a second client (one that I built) and moved it to the new test group and initiated a full image backup. The backup seemed to go fine, but the restore hit the same error. I then tried one of the COW backups from this client and restore completed without errors and test computer boots up as the image provided.
Would the new full vhdz image (with a previously used COW image settings) work on it’s own?
After testing (and failing) on two Windows clients, I am guessing this is not just a fluke. The Raw copy-on-write format works in testing, but both VHD and compressed VHD cannot be restored via GUI. Although I’m sure I can get a drive restored via command line during testing, I don’t want to rely on that when I am under pressure in non-testing situations.
What can I do to make the VHD format work via GUI?
Sorry - I mixed up the posted info because I started testing on a second client that only has a 500GB drive. This is from the client I initially started this thread about:
C:\WINDOWS\system32>fsutil fsInfo ntfsInfo C:
NTFS Volume Serial Number : 0x50ecfca5ecfc870e
NTFS Version : 3.1
LFS Version : 2.0
Total Sectors : 1,926,088,703 (918.4 GB)
Total Clusters : 240,761,087 (918.4 GB)
Free Clusters : 226,846,080 (865.3 GB)
Total Reserved Clusters : 60,728 (237.2 MB)
Reserved For Storage Reserve : 0 ( 0.0 KB)
Bytes Per Sector : 512
Bytes Per Physical Sector : 4096
Bytes Per Cluster : 4096
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 552.75 MB
Mft Start Lcn : 0x00000000000c0000
Mft2 Start Lcn : 0x0000000000000002
Mft Zone Start : 0x000000000127bb00
Mft Zone End : 0x0000000001288320
MFT Zone Size : 200.13 MB
Max Device Trim Extent Count : 0
Max Device Trim Byte Count : 0
Max Volume Trim Extent Count : 62
Max Volume Trim Byte Count : 0x40000000
Ok, so the bug might be that it accidentally sets version in backup_images to zero if you have a connected client, then set the image backup format to cow-raw and then back to vhd(z). After setting it back and forth it will create images with version=0. And those don’t fit onto the partition (and the wrong data gets restored if they would fit on partition).
Workarounds:
Fix the existing images: UPDATE backup_images SET version=1. Restart the server each time you set the image backup format from vhd <-> raw.
OK - There is progress. I am not too worried about existing backups from the test, so, once again, I placed my test clients in the test group, checked that the image format was vhdz, stopped the server and started the server. The version on my new test client’s full image backups now indicate 1, so I felt better.
Attempting to restore a new image started out without sizing error. Restore status indicated “0%” for about 15 minutes for the ~50GB partition and then the status went immediately to 100%. Watching the server GUI activity tab during this time indicated that the restore required time was 2 minutes. After the client’s restore screen came to 100%, five minutes later the bottom of the screen indicated: “WARNING: Read Timeout: Retrying”. Client indicates no more new messages (yet).
The server log entry:
2020-11-11 07:28:38: ERROR: Writing to output pipe failed processMsg-1
Client restore_wizard.txt:
2020-11-11 07:26:35: Login Response: err
2020-11-11 07:26:35: ERROR: Error during login: err
2020-11-11 07:26:45: Login Response: ok
2020-11-11 07:27:39: Restoring to mbr.dat
2020-11-11 07:27:39: Selected device: /dev/sda Partition: 2
2020-11-11 07:27:49: Restoring to /dev/sda2
2020-11-11 07:43:33: WARNING: Read Timeout: Retrying
And client restore_mode.txt:
2020-11-11 07:26:45: rc=0 hasError=false state=3
2020-11-11 07:26:45: rc=0 hasError=true state=0
2020-11-11 07:26:56: ClientService cmd: GET BACKUPIMAGES
2020-11-11 07:26:56: Waiting for pings…
2020-11-11 07:26:56: done. (Waiting for pings)
2020-11-11 07:26:56: rc=0 hasError=true state=0
2020-11-11 07:27:05: ClientService cmd: PONG
2020-11-11 07:27:15: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL capa=0&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:27:15: New channel: Number of Channels: 2
2020-11-11 07:27:39: urbackupserver: No available slots… starting new Worker
2020-11-11 07:27:39: ClientService cmd: DOWNLOAD IMAGE#pw=O5DbOLANpgegh7Xw5LbGInU6RDKQ6e&img_id=637819961&time=1605058097&mbr=true
2020-11-11 07:27:39: Downloading image…
2020-11-11 07:27:39: Waiting for pings…
2020-11-11 07:27:39: done. (Waiting for pings)
2020-11-11 07:27:39: In mutex…
2020-11-11 07:27:39: Downloading from channel 0
2020-11-11 07:27:39: urbackupserver: No available slots… starting new Worker
2020-11-11 07:27:39: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL capa=142649&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:27:39: Imagesize 556
2020-11-11 07:27:39: rc=0 hasError=true state=0
2020-11-11 07:27:39: Downloading MBR…
2020-11-11 07:27:39: Downloading MBR done
2020-11-11 07:27:39: Download done -2
2020-11-11 07:27:47: Internet mode not enabled
2020-11-11 07:27:49: ClientService cmd: DOWNLOAD IMAGE#pw=O5DbOLANpgegh7Xw5LbGInU6RDKQ6e&img_id=637819961&time=1605058097&mbr=false
2020-11-11 07:27:49: Downloading image…
2020-11-11 07:27:49: Waiting for pings…
2020-11-11 07:27:49: done. (Waiting for pings)
2020-11-11 07:27:49: In mutex…
2020-11-11 07:27:49: Downloading from channel 0
2020-11-11 07:27:49: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL capa=142649&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:27:49: urbackupserver: No available slots… starting new Worker
2020-11-11 07:27:49: ClientService cmd: GET DOWNLOADPROGRESS#pw=O5DbOLANpgegh7Xw5LbGInU6RDKQ6e
2020-11-11 07:27:49: Sending progress…
2020-11-11 07:27:49: Imagesize 500000882176
2020-11-11 07:27:49: Used bytes 500000882688
2020-11-11 07:27:59: Client timeout in ClientConnector::Run
2020-11-11 07:28:00: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL capa=142649&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:28:10: Client timeout in ClientConnector::Run
2020-11-11 07:28:11: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL capa=142649&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:28:15: ClientService cmd: PONG
2020-11-11 07:28:21: Client timeout in ClientConnector::Run
2020-11-11 07:28:22: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL capa=142649&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:28:32: Client timeout in ClientConnector::Run
2020-11-11 07:28:33: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL capa=142649&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:28:37: rc=0 hasError=true state=3
2020-11-11 07:28:41: rc=0 hasError=true state=0
2020-11-11 07:28:41: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL capa=142649&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:28:51: Client timeout in ClientConnector::Run
2020-11-11 07:28:52: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL capa=142649&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:29:02: Client timeout in ClientConnector::Run
2020-11-11 07:29:03: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL capa=142649&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:29:13: Client timeout in ClientConnector::Run
2020-11-11 07:29:14: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL
[many repeats every 10 seconds]
capa=142649&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:40:25: Client timeout in ClientConnector::Run
2020-11-11 07:40:26: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL capa=142649&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:40:36: Client timeout in ClientConnector::Run
2020-11-11 07:40:37: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL capa=142649&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:40:43: ERROR: Read Timeout -2 CS
2020-11-11 07:40:43: Download done -2
2020-11-11 07:40:43: Client timeout in ClientConnector::Run - Channel (total timeout)
2020-11-11 07:40:43: ClientService cmd: GET DOWNLOADPROGRESS#pw=O5DbOLANpgegh7Xw5LbGInU6RDKQ6e
2020-11-11 07:40:43: Sending progress…
2020-11-11 07:40:47: Client timeout in ClientConnector::Run
2020-11-11 07:40:48: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL capa=142649&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:40:48: New channel: Number of Channels: 1
2020-11-11 07:41:48: ClientService cmd: PONG
2020-11-11 07:42:48: ClientService cmd: PONG
2020-11-11 07:42:48: rc=0 hasError=true state=3
2020-11-11 07:42:48: ClientService cmd: #IgsZlIMHXFghhDSq6wQOk#1CHANNEL capa=142649&token=ZnaOhyBmhx4DSaBLhgDF&restore_version=1&virtual_client=
2020-11-11 07:42:48: New channel: Number of Channels: 1
2020-11-11 07:43:48: ClientService cmd: PONG
2020-11-11 07:44:48: ClientService cmd: PONG
2020-11-11 07:45:48: ClientService cmd: PONG