For example, (2) and (4) could be activities like:
Doing any work that doesn’t require the Qubes machine
Exercising
Reading
Cooking and/or eating a meal
Running errands
Making some calls
Cleaning the house
Gardening
Going for a walk
Playing sports
Playing computer/video games
Having tea
Meditating
Personal care/grooming
Going out somewhere
Watching TV shows and movies
Taking a nap
Mine usually doesn’t take that long, but I think that can be okay sometimes if you have other things you need/want to do (such as the ones listed above).
You don’t have to wake up in the middle of the night. You can just start the verification when you wake up, then do other stuff and come back later.
You don’t have to stick around. You could go out and do stuff, then come back and do the next step.
Ah, well, if uptime availability is important to you, then this method isn’t suitable for you. You should probably instead use a script to do the whole backup process while you sleep so that your computer is available for you to use the whole time you’re awake.
I expect that every reasonable, reliable operating system should guarantee a high availability for the user (99% maybe?), don’t you? Due to this problem, Qubes doesn’t, unless you skip regular backups, which is what people do (including myself).
Concerning the terminal commands, I commented above.
“But my system is unusable while I’m making a backup because I feel the need to keep all qubes shutdown or paused during the backup due to Spectre/Meltdown speculative-execution-type risks,” you might say.
That’s your decision, and no other OS protects you from that. It’s disingenuous to fault Qubes for giving you the option to protect yourself from something when no other OS gives you the same option. If you don’t want to use the option, don’t use it. If you want to use the option, accept the trade-off.
“But my system is unusable while I’m making a backup because the system load is too high,” you might say.
That’s not what “uptime” or “high availability” are referring to. That’s like saying, “My Windows system load is too high while I do video encoding or [other resource-intensive task], therefore Windows doesn’t provide 99%+ availability.”
Do you care about possible Spectre- and Meltdown-like CPU vulnerabilities? Do you use your Qubes OS normally while backing it up or do you Pause All VMs for Secure Operation?
I don’t see how pausing a VM protects the data in it from side-channel attacks. Paused = in RAM. Even after a shut down, some data still remains cached, unless there is some explicit mechanism which zeroes/shreds/otherwise-overwrites the content of the memory cells used by the VM.
AFAIK this kind of attack allows to leak data by repeatedly compute something and extract all the data processed in SMT.
It is far more complicated and not all side-channel attacks rely on simultaneous multithreading.
If the VM is paused, nothing from it should go through the CPU, so you should not be able to leak data of paused VMs.
Pausing a VM does not remove it from memory and there is no per-qube memory encryption. With a vulnerable CPU, meltdown can read the whole memory (it melts down normal hardware security boundaries).
I think you misunderstand the point of my reply. I am not here to complain how bad Qubes OS is compared to other OSes (it’s not!). I am replying to the question of the post, why people don’t do frequent backups. Qubes promises reasonable security, and people who need it will probably stop all qubes during the backup. When you care about the security, you will likely experience this problem, which I described, which is why I am explaining why it should have a high priority.
All users who actually value security will suffer from the problem I mentioned.
You should pause the untrusted VMs, not the trusted ones.
While I am at it, I will try to see if the time/space estimates of backup could be improved (but I won’t promise that).
I have not looked at wyng deep enough. Does it have a GUI? Maybe I could work on it (far far in the future).
1, 2 & 3 has been on my todo list. The time has come.
p.s. Another constructive suggestion is Issue #2653 from 2017. It would be easy to add a README.text file to the backup. It could contain generic information and a link to the most recent on-line guide on backup & restore.
Backup necessitate another drive, a setup that most will just skip until their first crash, or the second one, and most who have never experienced a total crash don’t know how important it is, and most importantly don’t know: it does happen (whatever the drive)
I learned it the hard way when my NAS (5x 4To) in RAID 5 crashed … no backup of a NAS, the NAS IS my backup, it is meant to serve for decades, it is robust, it is …
Well, it is as strong as the weakest link, which are the HDD themselves, and they do fail. In my case, to make it worse, I didn’t notice the first drive failing, but only when the second one, a few weeks later failed, and as I was to simply replace it, I noticed the first one was already gone … one can’t regenerate a RAID 5 with only 3 disks out of 5, so … totally F**d
My new setup is RAID 6, and I still don’t have backup but I took note of the date I installed those new drives, and keep in my calendar the 5y lifespan rule.
you can still have a file system corruption, a software bug or an attacker doing something on your files (ransomeware for instance)
RAID 6 is a better choice for the availability of your data, if you have one failing drive it gives you time to replace it and resilver the RAID. In a RAID 5 situation, you have a high chance of having a disk failing during the long resilvering operation which could just lead to the loss of the RAID array
I have 3 NVMe, 1x 512Gb, 2x 2To, so roughly 4500Gb; According to your estimation, I would need 46Hours per BU. And if I apply the “you need at least twice” then I would need a 9To back up drive just to keep 2 BU …
Taking my MX23 as a reference, I would love to have options like:
Dom0 backup every week,
User added VM (Templates) every day
Chosen/Specific User added VM (Running); Including Win$; including data; every hour, or twice a day
Disregard default templates and running VM as they are easily regenerated if I need to reinstall the system
We all agree, it’s just a pain, too much dedicated “work” to do something that could/should be automatized better, especially for all those out there who had the experience that BU didn’t fully restore, useless, corrupted, or even just “not the right one” as in: My last back up was automatically generated right after I did this or that update, so the problem (reason why I want to BU) is already included inside the BU, making it useless, or that I completely forgot to do the last BU, so I have to go back in time XYZ days to the previous one, which will have me reinstalling everything I did by then, yet alone all my documents I’ve updated which I will have to type again (as not part of the last BU)
There are so many reason not to rely, not to like, not to do any BU
Or from time to time, do a complete image of the disk(s) and if needed, restore the entire system completely
But in my case, I would still need a couple of 6To disks to keep several BU…
Back to my comparaison reference, on my MX23, I have a 1To Sabrent attached permanently, it’s LUKS and it received and keep the last 5 Boot-up BU, the last 3 Weekly BU, and the last 48 hourly BU, and my 1To is not even half full.
All data is BU’d on a specifics USB drives (Apricorn) which I swap every other BU.
I use DetWinner or CZKawka to clean up doublons then.
Maybe I don’t know what I’m talking about or misinterpreting your statement. But I don’t think that it makes sense to solve this problem on the OS level.
The QubesOS backup tool focuses on backing up qubes because that is within its domain. The purpose of QubesOS is to manage qubes. It doesn’t have any context for what is contained within those qubes. For example, I have one qube which is primarily used for working on source code and another qube that stores podcasts, ebooks, etc. My backup/versioning needs are very different for source code vs media, but QubesOS doesn’t have that context. I don’t think this is a deficiency with the QubesOS backup tool, I think that this is an inappropriate expectation for users to have of QubesOS.
To be clear, I’m not saying that Invisible Things Labs shouldn’t work on a data-oriented backup tool. It’s clearly important to at least some of your clients. And if you develop it then it might make sense to have it available by default in QubesOS installations. But it’s not an OS-level tool.
I guess Qubes OS default templates could implement btrfs regular snapshot + a tool like timeshift to browse the snapshots easily
This would solve most needs of “I accidentally deleted/modified this important file” by providing a simple mechanism to recover it from an earlier snapshot.
but I took note of the date I installed those new drives, and keep in my calendar the 5y lifespan rule.