Multiple backups having issues restoring...
I have 2 backups that are useless that I can't use.. Probably more.
This is completely unacceptable that you still have not resolved these bugs I mentioned in Qubes version 2. Please fix!
================================================
Extracting data: 11.1 GiB to restore
ERROR: unable to extract files for /var/tmp/restore_4y7IsA/vm31/private.img.027, tar output: tar: vm31/private.img: Cannot write: No space left on device tar: Exiting with failure status due to previous errors
Some errors occurred during data extraction, continuing anyway to restore at least some VMs
-> Restoring QubesHVm win7x64...
-> Done. Please install updates for all the restored templates.
Please unmount your backup volume and cancel the file selection dialog.
Finished with errors!
------------------------------------------------
There was 18 GB on the dive where I was restoring to.
1. Why isn't it restoring to where it's meant to restore?
2. Why is it restoring to the operating system partition?
3. Why doesn't it check space BEFORE it starts?
4. If there isn't enough space why doesn't it restore to where it's told to?
================================================
Extracting data: 18.5 GiB to restore
Some errors occurred during data extraction, continuing anyway to restore at least some VMs
-> Restoring QubesTemplateHVm Win7x64...
ERROR: VM private image file doesn't exist: /var/lib/qubes/vm-templates/Win7x64/private.img
*** Skipping VM: Win7x64
-> Done. Please install updates for all the restored templates.
Please unmount your backup volume and cancel the file selection dialog.
Finished with errors!
------------------------------------------------
private.img does exist in the archive/backup.
Why isn't it knowing that and restoring?
================================================
Quick question, were the VMs backed up from a Qubes install with multiple storage pools, by chance?
I am about to create an issue about that as soon as I can grab proper logs. It looks very similar to your problem, and the very specific nature of the case can explain why it was never solved. Just a shot in the dark.
Cheers,
///Pablo
sda1 /boot
sda2 /
sda3 /var/lib/qubes
I also have
sda1 /boot
sda2 /
sdb1 /var/lib/qubes
Thing is, I used to be able to restore them and all, BEFORE I updated the manager.
The only difference between 2 PCs is the version of the manager.
Why doesn't it restore to where I tell it to instead of trying to restore to the tmp directory AS WELL as the location I say?
The whole methodology of it is just unknown.
It does one of 5+ different things when it stuffs up.
So multiple storage pools or not, doesn't matter.
On another PC I have several storage areas, and I just use links from the /var/lib/qubes/*/{GUESTNAME} path to where the guests really are stored.
So just saying it's multiple storage pools is not really accurate as to the issue. There is something more in-depth than that. It could fail on a drive that has no partitions at all, and mine do at times.
There are also times when it expands the guests drives to 100% size instead of being thinly provisioned.
HVM, AppVM, HVMTemplate, HVMTemplate converted to VMTemplate, or anything, doesn't matter.
If you need more details, let me know.
There is A LOT that I can tell you about this one thing, restoring, that has issues that have not been resolved.
MMCBLK is /boot and /
16 GB SDCard.
Can be set as Read Only as it will not change (but r/w at the moment until I know for sure.)
Log folder set on HDD.
HDD is set as (technically) /var/lib/qubes
But I doubt that that will have any different effects than any other way that I have things.
sorry for being confused. but are you saying it fails to restore, or just don't like the method it uses?
I'm saying it fails.
Often BECAUSE of the method it uses.
Sometimes because of other things it does because it doesn't create the file before it tries to put the data into the file.