On Monday, September 2, 2019 at 6:11:58 AM UTC+2, Andrew David Wong wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 01/09/2019 3.46 AM, 'Heinrich Ulbricht' via qubes-users wrote: > >> Personally, I would just stick with this. In other words, I would treat > >> the new Qubes installation as completely new and use qvm-backup-restore > >> as the only mechanism for migrating my old data to the new > installation. > >> This is the only way I would be confident that I weren't screwing > >> anything up. > >> > >> > > Thank you very much for helping me out on this, awokd and Andrew. > Currently > > I'm leaning toward taking the safe path. If I understand correctly that > > means: > > > > 1. Backup everything that's on the SSD *and* the external storage > pool > > HDDs - this will take a lot of time and space but that's the price I > have > > to pay for the safety I get > > 2. Connect the new SSD, wipe the external drives > > 3. Install Qubes OS on the new SSD > > 4. Create external storage pools on the additional HDDs > > 5. Make the SSD the default pool; restore VMs for SSD > > 6. Make external disk 1 the default pool; restore VMs for this pool > > 7. Make external disk 2 the default pool; restore VMs for this pool > > 8. Switch default pool back to SSD > > 9. Done > > > > How does this sound? > > > > I haven't personally used external storage pools, so I can't comment > there. (Thankfully, though, others have already weighed in on that part.) > > Related to Brendan's point, in step 1, it's important to *verify* the > backups you've just created. > > GUI: Qube Manager -> Restore qubes from backup -> [x] Verify backup > integrity, do not restore the data > > CLI: qvm-backup-restore --verify-only [...] > > As the saying goes: Backups always succeed. It's restores that fail. > > (If you have the extra disks, it would technically be even safer to > use new HDDs and refrain from wiping the existing ones until after > you've verified that everything is correct in the new system, but this > might be overly cautious. I personally don't feel the need to do this > anymore, because I know the data is already there in a verified Qubes > backup, and I've tested my ability to manually recover it > independently of Qubes as a last resort.) > > Aside from these caveats, your plan sounds like what I would do. > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl1sloEACgkQ203TvDlQ > MDDqdg//cFoY4k/EFm5t2pVpoiFKubh/o34CzJo8eYfOWgHaNnnVlhfqXGartWkS > F5aSeig2PiPWpPqfJ9G4mWV46ySjC/hez0fSmAl2rsNA/PaRTAG/aIhIy7DlNuoo > H9MQJw5TsiHvgz6h/FfYVOcl1/mDOwmVw4n9WQ1x49bgsmI+CdZf94c7P+XvEpde > YM3G2hGi6e1Bd3H3Xm1B5EtovsMXC3ieDkXDYlun814t1jBv0BmVib93vRaltHIt > Bdd766BAvhkdMOOWONHfmOrw1An7FBm1uKIxdJb71w5Kltv8VV1S7xXq387/QmGF > fcdJljdEtArgxg4Pe35i03GseDjRfw1rhsH3TL/8PDjY2P1n+lwI5JG8+fa7ZPUM > FHKoQAiPk9D3d8vOXmnwVT8QrCdaJvnX0bqtihusUnUh13+ZCrP5akq3KE7hrIn3 > dgVG6eywbwS/Y18pbXChdvDdz3kx6Q05cB56nsFfyR65amLJh7F3NmkVd20HBDoh > yNxEqWMaHLiz/chOLLXFxUy8nAor/CQ8JgRPbERh40M5l67jzhFEXgHRl5u4XmbM > g8iNpYbFoUsBDP8bSzgPIFaNJ/OuUGnNsXtyYGwfxTzH45UMHLqGCqAPPdRUqaRB > W3JYH81cFnRVJdqBU+bj+1GPyD6an31++0ahJFX11DawHiP8nEc= > =d7uO > -----END PGP SIGNATURE----- > > Here is an update on how my migration from SSD_small to SSD_big is going so far.
Just as a remindet this is the challenge I face: * dom0 SSD has 100 GB capacity, ~10% of this is free (that's why I want to migrate to a new SSD) * external storage pool 1 has 1 TB storage, AppVM *1* with < 500 GB private storage in use * external storage pool 2 has 1 TB storage, AppVM *2* with > 500 GB private storage in use * I want to migrate everything via backup+restore to new disks/pools *Here is what worked* * backing up App VMs from all 3 pools using built-in backup mechanisms (UI) - cool *Here is what did not work* * *verifying* the huge (400-700 GB) backups *did not work* since this filled up my dom0 pretty fast and then failed -> this is the reason why I resorted to what Andrew wrote: having the original still in place while restoring to different disks, not overwriting anything, just in case restoring fails * *restoring* the huge (400-700 GB) backups *did not work* since this filled up my dom0 pretty fast and then failed -> this is exactly like donoban wrote; I managed to work around this for AppVM *1*, NOT for AppVM *2* (yet) To restore AppVM *1* (< 500 GB) I modified *restore.py <https://github.com/QubesOS/qubes-core-admin-client/blob/9158412a24da300e4c54346ccb54fce1e748500f/qubesadmin/backup/restore.py#L858>* to restore to another location than */var/tmp*. The easiest for me was to create a new (temporary) AppVM in my new 1 TB external storate pool *1*, to increase its private storage to 500 GB, to mount its private volume to dom0 and to use this path as temporary location in *restore.py*. So I was using my 1 TB disk both as restore target and temporary location for backup extraction. I was lucky - the pool filled up to 99.8% and the restore succeeded. So currently it seems you need double the amount of storage your to-be-restored AppVM consumes to restore the AppVM. Now there is one challenge left. I have to restore AppVM *2* which is about 700 GB. To my current knowledge I would now need to have twice this amount to restore - which currently I don't have. This is why I'd like to somehow slow down the extraction. donoban mentioned this is possible. I had a look at restore.py <https://github.com/QubesOS/qubes-core-admin-client/blob/master/qubesadmin/backup/restore.py> but honestly have not idea where to start. I also currently don't know how the different extraction processes interact and how the backup is structured. Can anybody suggest a modification (or hack, however dirty - it's meant to be temporary) to restore.py so it won't need 700 GB of additional temporary storage when I try to restore my 700 GB AppVM? Thanks for all your input so far. Knowing that dom0 could fill up certainly saved my some hours of questioning life. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/90ead0e1-bdbe-4079-8b53-78042a4ffd8a%40googlegroups.com.
