I’ve been running backups using a dedicated qube, on some of my larger qubes. My normal process is to create the backup on that “backup” qube, and then later transfer the file to an external HD and/or the cloud. (I find that trying to write directly to the external HD isn’t efficient and doesn’t always work well.) I have enough overall disk space to do this.
I just went to do this again today, and got a varlibqubes full message (and the backup failed due to disk space). I expanded the size of dom0 and tried again. Now it’s full again and the backup failed. I’m assuming it’s some sort of temporary file being created in dom0 by the backup process? If so, can you tell me where to find it so I can delete it?
Thanks!
1 Like
Thanks for responding so quickly. I cleared that folder out, and it still wasn’t solving the problem. But then I discovered my mistake - the last couple backups I tried I hadn’t put in my special qube - I had saved it in dom0 instead. So no wonder it was filling that up. Deleted those partial backups and everything was fine.
4 Likes
I just had the same issue 
Figured out what went wrong:
Qubes Update GUI tool remembers the last chosen destination qube, so I assumed I did not have to select again. However, if that qube is not running, it will default the selection to dom0.
4 Likes
This has happened to me also.
Is is a candidate for raising an issue?
My preferred behaviour would be for the previous backup VM to be quite persistent, unless it was an un-named and no-longer running dispvm.
(Edit: to clarify, the settings for backup destination should be persistent. There is a complication, when the VM is not running, or the destination directory is a mount point, but is no longer mounted.
These would be more complicated to handle. Maybe a button to Start the VM would be helpful, and an alert symbol plus text if the directory “status” has changed?)
1 Like