Hi, im just playing around with urbackup and made a full image backup. now trying to restore it to another drive (to test restore). I can select images etc and when starting to restore it goes:
Is there any log files somewhere that can give me any data? either on server or client machine? Tried to google the answer but i dont find anything…
Check the version of urbackup restore, last time I check about two weeks ago, latest verson of restore iso had an issue of restore speed, it was like it wasn’t, so got newer from git, and it’s ok, try some from Index of /downloads
BTW.
Always a good practice is to check from time to time how it’s working using vm etc.
There are log files at /root, e.g. /root/restore_client.log . Maybe there is something helpful in those.
Also perhaps look at processes with htop if any hang in D state and at kernel messages with dmesg.
IIRC this happens if the destination drive is too small, has to be at least as big as the drive that was imaged, noting that 2 e.g. “512GB” drives from different manufacturers may not have the exact same number of available bytes.
An clear reported error would be more appropriate than just hanging, but…
I’m not 100% sure yet but yes. Seems like the issue was caused by a different sizes of disk. Did a tests with virtual machine and its restoring at the moment…
Its also weird that if my drive is 30GB (test drive) and image size is 10Gb then it restores the whole 30Gb tho i have 10GB data to restore…
It just says the total drive size, but usually it just “ends prematurely” once it’s gone through all actual data
If the drive was 30GB then the partition is 30GB and has to be restored as is
yup just saw it with my restore. Thanks for all the help and kilrah, your info was 100% accurate for my issue
If, as I would expect, urbackup takes a raw image of the drive then a 30Gb drive will create a 30Gb image. In order for urbackup to only image “the part of the drive that is actually used”, then urbackup would have to be aware of the filesystem in use (FAT, NTFS, EXT4, etc.) And calling the results of using the filesystem an “image” would be a stretch of the word image. I am not saying that urbackup does not or could not use the filesystem to make smaller backups - other existing software indeed does exactly this - I’m just saying that I don’t think urbackup does this.
The fact that your 30Gb drive image only took 10Gb of disk space to store is probably the result of compression. The image would have to be uncompressed on restore, so it would jump back up to the original disk size at that time.
Just in case someone has something similar and is stuck.
I recently replaced a faulty drive with a used drive that had a “unique” GPT partition signature that could not seem to be cleared that was causing the same fault “stuck at 0% writing MBR to disk”.
The only solution since Gparted couldnt even clear it - was to boot a Linux Rescue disk that has sfdisk (I think I used debian 11 if memory serves, the run sfdisk to delete all partiions on the target drive with:
sfdisk --delete /dev/sda
Only then could I use said drive and restore from the bootable UrBackup image.
I mention it here to save someone time, since it was quite odd (the unique “untouchable” GTP partition)
i have same issue . have you remove this issue ?