Is it possible to add a new kind of back-up tool? I mean with current back-up tool, you have to do full back-up everytime you wanna back-up. Won’t it be time efficient, if the tool backs up only the new data, that is added or deleted?
I mean like Google photos or Dropbox. But encrypted.
You can use any backup tool in the domUs, as long as it can run in a virtual environment.
In dom0 you probably want to just use the tool provided by Qubes, you don’t want to install a lot of 3rd party software in dom0, you also don’t have networking.
When you ask yourself what new data actually is and is it security wise to restore it, you’ll probably reconsider using any backup tool at all, since it would be probably much easier to manually copy it to backup location.
I learned from @adw that taking notes is extremely wise on setting Qubes and used the suggestion as personal best backup tool. I just (re)install clean system and follow the notes.
This suggestion is mainly intended for templates (e.g., list of packages to install, steps taken to configure and customize programs), since the data is publicly available on the internet and can be redownloaded. However, most users also have irreplaceable data (e.g., photos, emails, documents) that can’t be recreated from just notes.
Data security has more aspects than merely secrecy. Perhaps you know about the InfoSec CIA triad. Confidentiality (which you seem to refer to as security) is just one of its aspects. Integrity and availability are the other two and a good backup system is necessary to ensure data availability. IOW, a decent back up is part of data security, not a compromise in it.
I agree that Qubes backup system is quite inefficient. That’s why I also asked about Bacula in another thread but it seems that got buried.
Exactly, and that’s what I meant on with:
I agree. I will repeat: what data? And when the one answers and hopefully realize that backing whole qubes probably isn’t security wise nor mostly necessary, then it might be concluded that manual copying new data is easier and less cumbersome.
P.S. I never mentioned secrecy, so I don’t know why did you put it in my keyboard.
I answered your repeated question in the other thread I mentioned and you stopped discussing further. I wonder why.
It is not less cumbersome to keep manual track of data modifications and copy those manually. A computer can do that much more efficiently and with zero burden to the user. If one is looking for an incremental backup solution, than one has most certainly felt the need for it. Would you agree to that?
P.S. I never mentioned secrecy, so I don’t know why did you put it in my keyboard.
Secrecy is good for keyboards! 
Alright, let’s say I misunderstood. I apologize. In this case, please clarify what you mean by “security wise” and how a good backup can reduce data security, considering your agreement with my previous reply.
This suggestion is mainly intended for templates (e.g., list of packages to install, steps taken to configure and customize programs), since the data is publicly available on the internet and can be redownloaded. However, most users also have irreplaceable data (e.g., photos, emails, documents) that can’t be recreated from just notes.
So, could one just back up AppVMs frequently, and templates perhaps infrequently but then again, perhaps not at all? (If your template creation is scripted or salted, then in theory you need never back them up, BUT you will want to back up your scripts and/or salt recipes, and you will want to do so THOROUGHLY (offsite backups, the works.)
By AppVMs I am talking about ones that the user gets onto to do things to his/her own data, not anything at the more “system” like level. Even though almost everything I have sits on a NAS in VeraCrypt containers (and gets backed up six ways from Sunday), there’s still a little bit of stuff on AppVMs I want backed up, but then, those tend to be the smallest VMs in terms of usage anyway. (At least they are if the data is minimal–the point being you won’t be backing up copy after copy of the same dang OS.)
Also, unfortunately, a lot of user settings live on those VMs, which is preferable to them living on templates IMHO unless you can script setting them.
This is what I do, daily backup of all appVM and weekly backup of the templates. I have two profiles for the backup tool I run with cron.
If you use the main Qubes manager gui, it’s a bit tiring to uncheck and recheck those boxes, but one could check only the AppVM boxes for automatic stuff (done daily) and then “manually” back up the templates by opening the backup tool and shifting qubes into the “do the backup” list.
My (user level) AppVM qubes all have names starting with a capital D and a number that maps to color (e.g., D5-Gimp) [that way they are forced to be ordered by color; D5 is blue], so they stand out; in the backup tool they are easy to spot and can be removed from the “to backup” list…or put there exclusively if you’re working that manually.
All of that could be easily scripted, and should be if you want to do something automatic. qvm-ls --raw-list (I think) will list qubes by name; you can filter out what you don’t want to back up by piping this through grep–in my case either anything that matches ^D or doesn’t. Or you could hard code the list but you have to remember to fix it when you create a new AppVM.
You don’t need to use the gui, you can save profiles in /etc/qubes/backup and use the backup tool from the commandline.
/usr/bin/qvm-backup --yes --profile <name>
Then just make two profiles, one for only the appVM and one for templates
It’s worth reiterating here that the Qubes OS security model assumes AppVM compromises as something that will happen on a regular basis.
Ah! I didn’t realize there was the possibility of independent profiles! Excellent. (For those who must use the GUI, I should look more closely, perhaps profiles are supported there as well.)
(My own usage tends to be a mix of GUI and command line, so when on here, I tend to suggest GUI for GUI-only users. I’ll tend to use the GUI where the command line syntax is complex or hard to remember (that latter, for things I don’t do often.)
As time goes on, I’m shifting more and more towards making my “user level” AppVMs actually be named disposables…so presumably any compromise goes away when I close it. It’s also an excellent way to ensure caches are cleared (and not just browser caches, also thumbnail caches and the like). Of course a named disposable would never need backing up, and its DVM template (which is actually an AppVM) wouldn’t need to be backed up often; only when you change it (mostly to change a user configuration setting).
EDIT: “so presumably any compromise goes away when I close it.” should read “so presumably any compromise to the DVM goes away when I close it.” (If the template (either the TemplateVM or the DVM template-which-is-actually-an-AppVM) [geez, we need a new naming convention] gets compromised, then of course this isn’t true.
I used to do the same, now I automatically back up all my appVM daily. I sometimes do manually run a full backup, if I know I might need disaster recovery, but it’s so rare I don’t mind checking the boxes manually.
I’ll probablhy be going into the manager, and checking the DX machines off first thing when I get onto the system tonight. And back up templates only right after a big spasm of updates.
The one thing it isn’t, is automatic. I haven’t really figured out a good way to do that, one that works for my circumstances. (I know how to do it, I haven’t decided WHAT to do.) The current location of my backups doesn’t work well for “automatic.” I need to give this some thought, and soon.
One thing I’d like to see is an option to not back up a VM–even automatically–if it hasn’t been started or updated (which entails a start anyway) or had settings changed, since the last backup. Presumably, under those circumstances, it hasn’t changed. I don’t know if there’s a way to check those times, even in a script.
On my desktop PC I got 2 TB raid 1 storage directly attached to dom0, it makes backups very easy.
On my laptop, I have the same issue with storage. What I think I’ll do is make a NFS qube and use that to copy files from dom0 to a network drive.
Right now I’m copying to an SSD in the same box. Which means the SSD must be mounted and I end up mounting it to a VM…one of the ones I want to back up! Uh, not good. Getting this done better hasn’t been much of a priority; I should by rights be putting the backups onto the NAS; where the backups themselves will be backed up and duplicated. Something to do this weekend!
Like I said there’s certainly an easy solution, I just haven’t put much thought into it…yet.