Hi,
I am currently replanning my backup routine and just wanted to hear what your routines are.
I am currently thinking about using 1tb usb stick (it supports 1gb reading, 900mb writing) and a micro sd card (also 1tb, never thought these little things can store so much!) as a second backup.
What do you think about my plan? And again: What are your backup routines (How often do you create backups, what hardware do you use, etc.)?
Hi
Usually follow 3-2-1 backup strategy. i.e.:
It states that there should be at least 3 copies of the data, stored on 2 different types of storage media, and one copy should be kept offsite, in a remote location (this can include cloud storage)
Follow a backup rotation scheme if you have more than 1 stick or in enterprise environments.
Differential backups for more frequent backups, incremental backups for less frequent backups. Full backups for archival (e.g. yearly).
modern backup software combine differential backup by only saving what changed between two backups, and full backups as every snapshots are atomic and contain everything 
I have a list of directories for each VM that I want to backup. For example for “the trusted browser”, that would be /home/user/.config/chromium, for “coding” (a standalone VM) thats /home/user, for “matrix” thats /home/user/.config/matrix and so on.
I create tar.gz archives of those dirs with a script. Backing up the whole VM doesn’t make sense to me, as building a new VM (cloning debian minimal, installing apt packages, creating an appvm) kind of takes the same amount of time it would to restore a whole image plus minus a few seconds.
I kind of treat my qubes like a throw away system. The only thing that matters is the backup + the setup scripts. I can wipe the luks header and other than the installation of qubes itself and downloading the debian minimal template, the restore doesnt take much time (I use apt-cacher-ng).
I kind of dream of a fully automated install for qubes OS, like what you do with preseeding for debian… Does that exist? LIke something to preseed all the questions you have during the install, maybe with the exception of the luks password.
Can you recommend a software? I believe there’s just a standard software that is the FOSS and most people in the Linux Community use it.
May I add something.
Use trees.
I have trees of all my backups. Any new backup, even before filtering it (i.e. removing any duplicate in it,) I run the tree command on it. I actually run two tree commands: one I call it “simple” and the other one “complex”… Basically, that way, if I had to only have cloud backups (for example, lost the local ones,) and I can’t download everything, I can download only the trees which will then give me the ability to know which part should I download from the cloud backups so I can have the file I’m looking for.
The “simple” is tree -a, and the “complex” is tree -ahD --du. When I’m looking for a file name, I look in the “simple” trees. When I’m looking for information about a file that I have its name, I look in the “complex” trees.
The most common are borgbackup and restic. However if you want to backup qubes, I can only recommend ANN: Wyng incremental backup, new version! which was tailored for efficient backups of disk volumes or disk images.
or my hack to use the official Qubes OS backup tool and pipe its backup to restic/borg to benefit from compress/deduplication instead of having to save the whole qubes every time.
Qubes has its own built-in backup tool, which is documented here:
This may or may not meet your needs. If it does, then it’s a simple and secure solution that doesn’t require you to install any third-party tools.
If you choose to use a different tool, make sure you’re aware of the security properties you may be giving up. (For example, Qubes backups feature authenticated encryption, which most DIY backup schemes do not. This is what allows you to securely restore from a backup without dom0 being compromised.)
Related:
May I ask a question? I’m really frustrated! Restic, for example, doesn’t allow creating backups without passwords. Same goes to MEGA: “We do end-to-end encryption! Yaay!”, or Sync: “We’re the most private and secure on the planet! Yaay!”.
I mean, seriously, do I misunderstand something? Why won’t I just encrypt my backups my self using gpg -c after creating backups with Restic, or before uploading to MEGA or Sync or so? Why would I ever not do that? I mean, I think I can even rely and be more rest-assured with my gpg -c than Restic, and than MEGA and Sync and everything else!
Why won’t I just create an anonymous account and upload files that I encrypted them my self using gpg -c to Sync? And then, if Sync is “The least private and secure on the planet! Yaay!” it will never matter, because I’m private anyway and secure anyway? (Disregarding the problems with Terms of Service regarding anonymous accounts or so. Just an example.)
Is this all really because: “most of people aren’t “advanced” enough”? MEGA, for example, is really famous with “We end-to-end encrypt for you for free! Hahaha! We’re good!”. Do they really do all of that because people didn’t take 5 minutes to know how to use gpg -c? It’s not only MEGA or Sync, it’s many more those are also happy and being proud that they “encrypt stuff”, for example, Proton Drive. Why won’t I just “encrypt stuff” my self?
I’m sorry that I may be asking this here and it’s not the place, but I really don’t know other places. Besides that I believe Qubes OS people are most likely the most security savvies out there! And this is related to this topic as well.
restic uses a specific storage format using a lot of files, how would you encrypt them all with gpg?
To add, I keep a minimal backup on a USB flash drive. I keep the latest signed ISOs for Qubes, Debian, and Tails, and then I backup specific files from dom0 and my vaultVM. I keep the ISOs on a public partition and the rest on an encrypted partition:
This, obviously, is not my whole routine, but it has proven valuable as a minimal working environment in a pinch for recovery and emergencies, especially for fixing Qubes when I do something stupid and it breaks. YMMV, but I’ve found it to be useful.
Isn’t it right that restic stores all the backups (all the important stuff) in the repository directory?
tar cz my-restic-repo | gpg --cipher-algo AES256 -o my-restic-repo-encrypted.tar.gz.gpg -c, then rm -rf my-restic-repo when succeeds. Won’t that effectively encrypt my repository? (Assuming my-restic-repo is the repository directory.)
And then whenever I want the repository to use it: gpg -d my-restic-repo-encrypted.tar.gz.gpg | tar xz. Isn’t that right? What will I lose if I just didn’t set a password while creating the restic, if I did that? (it doesn’t allow me, but say I just entered one letter.)
It’s stated on the Restic documentation, on the Encryption section: “The design might not be perfect, but it’s good.” That’s why I’m thinking gpg to be more secure or so.
There’s no problem at all that I use a complex password while setting the restic repository, as restic wants, and depend on it, and I believe I’ll be secure. But I just want to understand.
Please, please tell me, you’ve really made me worried! What do I misunderstand? I’m really using the gpg -c way to encrypt a lot of things and depend on it to protect them!
How did you come to the conclusion?