Your friendly reminder that RAID drives or replication are not backups 
1 Like
Agreed for the most part. What RAID will do (provided you set it up properly) is make your file system less likely to get corrupted. (OTOH many people use RAID to improve performance at the cost of reliability.) But that wonât help you recover files that you yourself messed up, or that got corrupted by malware.
Iâm not as sure about âreplicationâ though. It seems to me that making a copy of a drive can serve as a backup, depending on what you mean by replication. If itâs a moment-by-moment synching of the drive, thatâs really just a reliability increase. If instead youâre copying the whole drive to another physical device, that can be a backup, albeit a crude one where you have to mount it to get anything back from it (as opposed to having a fancy GUI that lets you pick the one file you want).
But to go back to the main point, itâs absolutely true that RAID is not a backup.
2 Likes
i try to do monthly backups. But yes, sometimes i run into storage limitations on my external ssd and the time it takes. Can we get a native implementation of Wyng-backups? I think this will be better for making regular snapshots. However, i think there are format limitations (btrfs vs ext4)? Not sure - havent used before.
I have used timeshift but then one of my backups failed when i needed it most⌠Will never use again
By replication, I meant software synchronization that keep directories synchronized with a server (nextcloud, seafile), or something like syncthing.
1 Like
TBH I think the long term goal should be the ability to do incremental backups (like BTRBK)
Only then I can see myself doing backups more frequently.
there are two methods to backup your qubes incrementally, but both are not official at the moment.
Whatâs the simplest?
From what we have learned from Qubes Summit 2024 presentations, there is a high probability for Wyng to be a part of Qubes OS 4.3. So it might be the recommended one.
3 Likes
I backed up the whole Qubes SSD with CloneZilla to a USB HDD and got asked if I wanted to decrypt luks or make a dd (sector-by-sector) copy⌠As I donât want to write empty space I selected decrypt and entered passphrase⌠Now you can set another passphrase for encrypting the backup which is then needed for restoration⌠But if I read correctly, luks stays decrypted, so what would happen if I restore the image? Would Qubes start with an already encrypted file system? And if yes, could I simply enable encryption again?
Thanks
From what we have learned from Qubes Summit 2024 presentations, there is a high probability for Wyng to be a part of Qubes OS 4.3. So it might be the recommended one.
Does Wying allow to customize what exactly inside the qube should be backed up and what not? Backing up caches incrementally is a really bad idea.
I believe no. It is developed for incremental backup of logical volumes. There has been an individual Github issue and a proposal to make the cache a separate volume for efficient backups. It is by the Wyng developer:
I believe no.
Then it is suboptimal.
I am thinking about a method like:
- a disposable (sys-backup) to which every qube is allowed to rsync (âthe Qubes wayâ, no network). Then rsnapshot can be used.
- that disposable âredirectingâ that rsync to the backup storage, so that it is transparent to the client being backed up
- each qube is synced to a separate dir on the backup storage, so one qube cannot possibly mess with the backup of another. Some per-qube fs-level encryption may be considered
- a dom0 script doing this qube by qube, restarting the disposable on each loop. It can also send each individual qube prefs to sys-backup
Obviously, this implies not working while backing up but it will be so much faster than the current method, that it wonât matter.
Thoughts?
please explain?
how do you handle this if you need to backup 51% of your total storage? the dispvm will not be able to handle this
also, rsnapshot does not allow encrypting data
with wyng, I can backup my 800 GB in 2 minutes, I donât care if it backups an extra 200 MB of cache that didnât change since last time. If you have some really specific qube with a lot of trashable data, you may not want to backup this qube, or clean it once in a while maybe
1 Like
We have to consider one fact. Wyng has been around since 2019. And many community members as well as some of the core team members have been using it. Wyng developer has established an excellent reputation among Qubes OS community.
Other backup methods are of course possible. Some of them might be better than Wyng in different areas. I am personally not using Wyng at the moment. But if I am going to look at an alternative to classic backup/restore, Wyng would be it considering the availability and stability.
please explain?
The numbers are examples.
Qube X:
/home/.cache = 1G, refreshed daily, backed up daily, 1G every time. In 1 month you will have backed up 30G of totally unnecessary data. Multiply that by the number of qubes with a lot of cache.
how do you handle this if you need to backup 51% of your total storage? the dispvm will not be able to handle this
Dry run first?
also, rsnapshot does not allow encrypting data
FS-level encryption can be used.
with wyng, I can backup my 800 GB in 2 minutes, I donât care if it backups an extra 200 MB of cache that didnât change since last time. If you have some really specific qube with a lot of trashable data, you may not want to backup this qube, or clean it once in a while maybe
Well, I understand but I am discussing optimization and principles, not individual case which works for one but perhaps not for another.
Can anyone using Wyng please explain:
- How do you restore the newest copy of an individual file from a particular qube?
- How do you track which file(s) changed between date 1 and date 2?
- How do you restore some data (not qube) to a non-Qubes system?
the answer to all your questions is âyou donâtâ
1 Like
The best workflow I could see for what you want is something I used to do.
- write a backup script using borg (or restic) in your templates to a ssh repository
- use split-ssh to give access to this ssh repository to your qubes
- store the repo password in dom0 and write a qube-rpc call to get the password from your qubes
from there, you can schedule the use of that backup script in each qube, you can decide exactly what to backup, and restoration can be done from a qube or from any qube.
itâs not perfect, and due to split ssh and the main password asking for a GUI confirmation, you can 100% automate it 
the answer to all your questions is âyou donâtâ
So, regardless of using Wyng or current Qubes backup, if you want to restore a 1K text file from a 10Gb qube, you must:
- restore 10Gb (assuming you remember in which qube it was, otherwise you may need to restore many qubes)
- run the qube
- search for the data matching the specific criteria
- obviously use a Qubes system too
IOW, in case you are not able to access the original data (hardware failure, laptop stolen, etc), there is simply no way to access even its spare copy unless you have a whole separate Qubes computer (which unlike generic Linux systems must satisfy a number of additional criteria). Unless you have this, your work just stops for indefinite time, during which you are exactly in the same situation as if not having a backup at all.
So what, precisely, does Wyng backup do for the user that Qubes backup does not?
Iâve long since come to the conclusion that it simply doesnât pay to put data on a qube, for many of the reasons qubist has mentioned.
EDIT: Or at least not data that is not also kept somewhere else, such things as configuration files, salt files, etc.