Hello all. I am a seasoned linux user, but I’m new to Qubes and I’m still figuring out how to migrate my workflow. For reference, I’m running 4.2.4. Sorry for shouting two questions at once, but somehow I felt that they match the theme of how to manage data in Qubes.
How multiple storage devices must be managed in the Qubes way? I’ve installed Qubes on a 240GB SSD, and I have some bigger HDDs which I would like to put to use. I’m aware of secondary storage official article, but I couldn’t understand if it matches my use case. The doc tells about using the secondary storage for storing qubes, but I am not sure this is what I want? I just want to keep the home files in that bigger secondary storage, but not the whole qube. I still want to keep on the fast storage all the programs and even the volatile part of the root filesystem. Is it doable?
Second question regarding data is the backup procedure. I am aware of Qubes Backup utility and some community hacks like the Wyng utility. As I understand these require manual interaction and perform volume backups but not see the files inside these volumes. That is a bit strange for me as I am mostly interested in restoring single files/directories but not whole volumes and I expect to have automatic backup routines. Is it too bad to continue using my current backup tools inside the AppVMs? In all the forum’s topics about backup that I’ve read, I’ve never seen anyone talking about doing a backup from within a qube. Is it because it’s too trivial or is there a obvious reason to refrain from doing backups like a regular desktop?
Besides the cultural shock of being a latina in a mostly US/EU community, I rarely interact with other people so sorry for any atypical word choice or way of speaking. Thanks in advance for your attention!
It may be possible with a lot if tinkering, not sure. IMO much easier solution is to store AppVMs on HDD and TemplateVMs on SSD, it almost exactly matches your use case, apart from the volatile part of the root filesystem and whatever programs you’ll install in the home folder.
You also could use -p instead of -P when cloning AppVMs to the HDD pool in order to only move private volumes there, leaving volatile volumes (which store the ephemeral part in AppVM’s case) on SSD
It’s your data, you define the optimal storage solution. I guess the main benefit of using Qubes Bacup is that it’s theoretically easier to use if you want to restore actual qubes (reality is up to your judgement, plenty of people have issues here). If you’re not interested in that, use whatever mechanism you like more. It’s all just lvm storage after all.
Also you don’t actually need to backup manually. You can automate it using qvm-backup command, for example.
If @otter2 's solution doesn’t work (I have used it so it looks good to me), you can create one or more app qube that uses the whole HDD. Then, inside that qube you can create volumes (I.e.: loop devices) that your regular qubes will access and mount.
I personally use both solutions. I use the Qubes Backup tool to backup some essential qubes (templates and app qubes) to be able to restore my system quickly. I also use another program to backup data, from the qubes. And I use Salt to record most of the configuration of the system.
Also I forgot to ask if HDD is used for /home or not? If it does, do you have it integrated into qubes somehow (like snapshots, etc.) or it’s just plain storage?
Wait why am I thinking that you actually do that… Yeah I should see myself off bye
Yes.
I think that you have already answers to this question.
If you want to store data and not the whole of /rw on secondary
storage you can also permanent;y attach a storage device to a qube, and
have it mounted in the qube for use.
I believe this to be a major issue with Qubes Backup, and therefore
Wyng. Neither provides the capabilities that you want: as you say they
are volume backups. I do not use them for that reason.
There have been many discussions of backing up data in a qube/qubes: most
recently in the thread on ““private.img”, attaching and backups”.
There are various approaches. You can run your favorite backup in the
qube, and export the data to some other qube, or somewhere outwith your
Qubes. If you want you can have a shared storage qube to hold those
backups.
You can use a separate backup qube (perhaps a named disposable), and
attach the private volume to that, mount it, and backup the data from
the mounted volume.
I use this approach - if you want TimeMachine like capability you can
backup data from a running qube, as well as from halted qubes. For
important qubes I do this. (Wyng requires the qube to be shut down,
which would be a major blocker for me.)
You’re doing fine.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I gave it a try today, but a lot of tinkering is not what I had in mind. I realized that throwing commands that I do not fully understand into dom0 makes me uncomfortable. Maybe in the future, with more knowledge of qubes internal commands, this path will fit me, but right now it isn’t an option.
I can see the benefit of restoring actual qubes and whole systems, but somehow I never could really find a need for it. It’s nice to learn that it can be automated though.
Now that you said it seems so clear! Attaching the HDD into the qubes and managing it the way I’m used to. Or better yet: partitioning the HDD (either in disk label or LVM) and showing only the logical volume to each qube. That way I even get the flexibility of, god forbids, sharing data between qubes if the situation demands.
This Salt beginners guide is a treasure that just got into my study-later list, but right now there is nothing useful to record on my system as I am still discovering how to organize my security domains.
You gave me interesting ideas. I confess I was at loss thinking how I would backup an offline qube. Thank you.
Good to known. Usually I do fine, but when I don’t, things not just fail but crash spectacularly, thus the disclaimer. Being social is already too much mind draining and it’s not fun to explain cultural differences after someone’s toes have already being unintentionally stepped.
That’s not what I had in mind but why not? Qubes OS is quite flexible so if you want something simple, you could use the secondary storage option, clone some app qubes and check if the performance issue is real.
Just keeping a list of installed packages is also a good option
