-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02/04/2019 8.04 AM, Ryan Tate wrote: >> On Apr 1, 2019, at 10:01 PM, Andrew David Wong >> <a...@qubes-os.org> wrote: On 01/04/2019 2.54 PM, Ryan Tate >> wrote: >>> >>> If the wish is not “restore” but rather to copy some files — >>> “some files and scripts that I need” — then it is up to the >>> user to transfer these files by the usual mechanism. >>> >> >> What is "the usual mechanism"? The main problem with the old >> behavior was that there was no reasonable way to get the dom0 >> home files out of the backup without clobbering the current dom0 >> home files that you want to keep. > > The usual mechanism would be however you would normally move files > from one machine to another. Not the backup/restore mechanism, > since he scenario of wanting to move some files and scripts to a > new machine is not backup/restore. >
In Qubes OS, qvm-backup[-restore] *is* the usual mechanism for moving dom0's home and VMs from one machine to another. This is because it is a violation of the Qubes security model to move files from a less trusted VM to dom0, and every other VM is, by definition, less trusted than dom0. Therefore, qvm-backup[-restore] is the only official, secure way to move files into dom0. Sure, maybe this doesn't fit some narrow, technical definition of "restore," but so what? For practical purposes, how does that affect users in the real world who are trying to get things done securely? If it really mattered, we could generalize the name to avoid using the word "restore," but the name doesn't really matter to that degree. For what it's worth, a lot of dedicated backup software also doesn't abide by this narrow definition of "restore." For example, a lot of backup software will deliver your restored files to you as a download, via email, or in a location other than the original location or computer from which they were backed up. "Backup and restore" doesn't have to mean restoring an entire machine state. In Qubes, it's about user-data-level backup. Using qvm-backup on dom0 is not intended to duplicate the functionality of lvm snapshot. > Why is file transport being shoehorned into the backup mechanism? > In order for some people to use restore for something other than > restore, I had to spend a bunch of time navigating through obscure > folders, copying with globs and mv and shunting aside old dirs, > restarting (multiple times), and crossing my fingers it would > work. Shouldn’t it be users who are doing strange, non > backup/restore things who have to jump through hoops, and people > who simply want to restore dom0 who get helpful default behavior? > All you had to do was move everything out of the restored subdirectory: $ mv home-restore-2019-04-01-etc/* . # move all normal files out $ mv home-restore-2019-04-01-etc/.* . # move all hidden files out Simple, quick, and easy, with no weird hoops to jump through. Now, don't get me wrong. I understand perfectly well that it's only "simple, quick, and easy" _if you know what to do_ and that this will _not_ be obvious to many users. But that's precisely why I suggested that it should be an option via qvm-backup-restore and the GUI tool. Make it discoverable so that users can understand that there are two possible outcomes and choose the one they want, then do it for them. > If people seem open to a change I’ll file an enhancement request. > Since I was already writing all this, I just went ahead and opened an issue for it: https://github.com/QubesOS/qubes-issues/issues/4946 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlykPh0ACgkQ203TvDlQ MDBe0w/+MdEEYakxVkGf1fA9lWl0gRM2wByzik0qR6yAjadA0JjdFB6zYNmSoW+7 Y0m2DLQ3N9CtA4dW/hcphJu0ujyNiV4HC0MVdbHPhsOSQSLckJ1wCrXR1zUPYDL2 egsB1cseT7n101y/zZt78DD9iCImurtkQZuF1wRHlYl8iVTgS+nE6BOPOxFd4rns htX939BJrzhPWPh0etra2c6SupNxBBJgtOieEMkHcFY+BiE9rH36bbia6JWJXDYk 1sVGggUM6LgteqCwKHr9bRB40rpllMLG9/k/uisPvEP9wBj2Z1eMJ8Vro0zcIexF 2aoRy1vMSNZuT49C3T6+ABvdcr+eqN9ahssMSDP5zitqTPZwgncAoPubTRaKmUth ST/50Cps3Hy7d5aYv8T/h1rClfwlw0c8tctYwFzjaeN45Vqjc7cAZzwv6IKOGPhE WLcIs46JDHpYbbxi1Tdb1FUYiFVShSUacVzHI+G6tQBVJ3n0Lh3r65ByYhiAexHJ HksFGMjDaJYF9dYeBwAtXgofCeOgYrIb1MR0Km7SnlRj9Acts/RrmGUS3ep8wm5/ MsLB+ykdujVFKahMi7mtCM717jMaahNCPxnU3gMCIUy8LqUo70vKFDR+xWG6AB6B piCB6wFYibkJPJjf4DagJJERnj7p6ej53+ZntZ9ZPohI/wfswKE= =+k1V -----END PGP SIGNATURE----- -- 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/2908866c-d372-ba40-602d-394c58a44199%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
