Well, I don't see any problem with restore. This is roughly what dom0 does (or initiates):
1. create a new VM (with default or explicitly provided parameters and no netvm – as I have mentioned, I don't backup anything but files and VM name) 2. start a new DVM (we have chosen to trust the DVM…) 3. attach the private.img to that DVM and mount it 4. add permissions for the DVM (BackupStorageVM allows the DVM accessing only the specified subfolder of backup) – well, it currently gets RW access, which is suboptimal (R access should be enough), but I don't se a real threat here. 5. start the backup script in the DVM (The script deletes everything but lost+found on the attached FS and starts restore.) Do you think I miss something important? Ad DVMs in QubesOS 4: Even cooler than I thought. My idea was to use the same DVM (maybe I am influenced with the current Qubes) in order to be sure we have Duplicity (or another software) of the version we want. But you have a point on the trust. This is even more interesting and it could be an important design shift. Maybe a template could know how to backup related AppVM's data. This is not a minor change, as it would allow using different backup backends for different VMs. And it is not so trivial, because we probably would want to use just one storage backend for all backups. Duplicity has a very simple API for backends (you have to implement just get/put/list/delete, it does not even have subfolders), but I am not sure about other backends. Anyway, the storage backends are going to be a challenge, at least a bit. With Duplicity not supporting subfolders, I rely on some features of the storage backends (subfolder-compliant URI scheme and automatic subfolder creation). This works with file backend (which is fortunately somewhat universal thanks to various fuse-based filesystems). However, with rsync, I had to implement a hack that violates encapsulation. (See https://github.com/v6ak/qubes-incremental-backup-poc/commit/83a285307042eb9363b5ed77e9701dcfa7ab3514 .) And I currently have no idea about other backends. Maybe the storage backend in BackupStorageVM can be quite generic (i.e., agnostic to backup backend), but maybe we can be badly suprised… TemplateVMs: I haven't published my idea, so I'll do it now: Backup list of explicitly installed packages and config files. I know, this is going to be package-manager-specific. There is not much a reason for storing backup of packages I can download. Ad StandaloneVMs: I agree it is tricky here. Currently, I backup/restore just private.img of AppVM. We definitely can't perform fully OS-agnostic file-based backup without cooperation of the OS (that is not yet installed). There are several ways how to handle it: a. Backup just private.img. I would be usually OK with this, because my StandaloneVMs don't have a large lists of packages, they are usually rather default installation with few additional packages installed. b. Handle root.img like TemplateVM and private.img like template-based VM. c. Handle root.img by block-based backup and private.img by file-based backup. Ad attributes: Good point. I honestly don't know what Duplicity supports. I am sure it has some basic support, so I concluded it is good enough for me, but maybe I should review its limitations again. Ad Windows: currently, it can theoretically mount private.img provided that there is ntfs module etc., so it should be possible to perform backup. I am not sure about attributes supported. The restore process for Windows will currently not work out-of-box without any further tuning. Thank you for your notes. Maybe we should follow Pareto rule. Maybe it should not be a goal to use file-based backup on everything. We can use file-based backup in most cases and use the current block-based backup in other cases. Especially when we integrate both backup types together – we could consider the current block-based backup as just another backup backend. My priorities are roughly: 1. Have good file-based backup and restore process for Linux template-based AppVMs. 2. Have similar process for Debian/Fedora TemplateVMs. 3. Have block-based backup backend. 4. Have good support for StandaloneVMs, Windows and other OSes. I believe this corresponds not only to my needs, but also to needs of many others. I am generally not against implementing something that has lower priority for me, especially if there is a pull request. ☺ Regards, Vít Šesták 'v6ak' -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d6da74af-f17c-4ca4-bcac-30ae1165cdc0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
