your overall Qubes system on different examples. You probably also noticed that there are commonalities among them. Most people need to use email, for example, so most people will need at least one email qube and a suitable template to base it on. But not everyone will need Split GPG (https://www.qubes-os.org/doc/split-gpg/), and not everyone will want to use the same email client. On the other hand, almost everyone will need a password manager, and it pretty much always makes sense to keep it in an offline, network-isolated vault. As you gain experience with Qubes, you may find yourself disagreeing with some of the decisions our fictional friends made. That's okay! There are many different ways to organize a Qubes system, and the most important criterion is that it serves the needs of its owner. Since everyone's needs are different, it's perfectly normal to find yourself doing things a bit differently. Nonetheless, there are some general principles that almost all users find helpful, especially when they're first starting out. As you’re designing your own Qubes system, keep in mind some of the following lessons from our case studies: You’ll probably change your mind as you go. You’ll realize that one qube should really be split into two, or you’ll realize that it doesn’t really make sense for two qubes to be separate and that they should instead be merged into one. That’s okay. Qubes OS supports your ability to adapt and make changes as you go. Try to maintain a flexible mindset. Things will eventually settle down, and you’ll find your groove. Changes to the way you organize your qubes will become less drastic and less frequent over time. Make frequent backups. (www.qubes-os.org/doc/how…-migrate) Losing data is never fun, whether it’s from an accidental deletion, a system crash, buggy software, or a hardware failure. By getting into the habit of making frequent backups now, you’ll save yourself from a lot of pain in the future. Many people never take backups seriously until they suffer catastrophic data loss. That’s human nature. If you’ve experienced that before, then you know the pain. Resolve now never to let it happen again. If you’ve never experienced it, count yourself lucky and try to learn from the hard-won experience of others. Keeping good backups also allows you to be a bit more free with reorganizations. You can delete qubes that you think you won’t need anymore without having to worry that you might need them again someday, since you know you can always restore them from a backup. Think about which programs you want to run and where you want to store data. In some cases, it makes sense to run programs and store data in the same qube, for example, if the data is generated by that program. In other cases, it makes sense to have qubes that are exclusively for storing data (e.g., offline data storage vaults) and other qubes that are exclusively for running programs (e.g., web browser-only qubes). Remember that when you make backups, it’s only essential to back up data that can’t be replaced. This can allow you to achieve minimal backups that are quite small compared to the total size of your installation. Templates, service qubes, and qubes that are used exclusively for running programs and that contain no data don’t necessarily have to be backed up as long as you’re confident that you can recreate them if needed. This is why it’s a good practice to keep notes on which packages you installed in which templates and which customizations and configurations you made. Then you can refer to your notes the next time you need to recreate those qubes. Of course, backing up everything is not a bad idea either. It may require a bit more time and disk space upfront, but for some people, it can be just as important as backing up their irreplaceable data. If your system is mission-critical, and you can’t afford more than a