On 2017-12-24 16:01, Andrew David Wong wrote:
> Hash: SHA512
> On 2017-12-24 19:08, yreb...@riseup.net wrote:
>> On 2017-12-23 11:11, Andrew David Wong wrote:
>>> On 2017-12-22 21:30, yreb...@riseup.net wrote:
>>>> On 2017-12-22 09:50, awokd wrote:
>>>>> On Fri, December 22, 2017 10:29 am, 'Tom Zander' via
>>>>> qubes-users wrote:
>>>>>> On Friday, 22 December 2017 02:42:57 CET yreb...@riseup.net
>>>>>> wrote:
>>>>>>> assuming 4.0 is going to come out of the box with like
>>>>>>> Debian 9 and Fed 26?
>>>>> If you have room for it, back up everything! You can restore
>>>>>  selectively later.
>>>> thanks for the two replies, *However, neither gets to the gist
>>>> of my inquiry. Namely, which VMs am I supposed to be backing
>>>> up,
>>> You should back up every VM that contains data that you don't
>>> want to lose and can't replace. For most people, this means
>>> backing up every VM that contains things like documents, emails,
>>> photos, and videos. If you're short on space, it's not necessary
>>> to make backups of things that you know you'll be able to
>>> download easily again later (e.g., an unmodified TemplateVM).
>>>> Dom0 (which for some reason is over *500GB!)  , hence  I can't
>>>>  backup "everything" even with a 2GB internal HD that I'm
>>>> trying to use
>>> For most users, the main reason to back up dom0 is because that's
>>> where your dom0 user settings are stored. Normally, dom0 should
>>> not be that large, since you're only backing up the home
>>> directory. (You're using qvm-backup, right?) It sounds like you
>>> didn't expect it to be that large, so if there's not enough data
>>> in your home directory to account for it, check /var/tmp to see
>>> if you have a lot of partial restores taking up space.
>>>> I was thinking of skipping the 1 large offline AppVM where I
>>>> keep old photos, and did, so why did  the Templates and Dom0
>>>> come out to such a *Huge filesize,   what would be typical ???
>>>>> From what your saying can I skip the Debian 8 Template, I
>>>>> have 2 AppVMs
>>>> and the Whonix stuff based on it I guess
>> What is the default backup location from the GUI VM Manager
> It looks like the default is dom0. (Not sure, since I usually use the
> CLI, but I just tried going through the first few prompts in the GUI,
> and the default target was dom0.)
>> : I'm wondering now where I backed up my 300GB VM with old photos
>> back in May 2017 ....maybe that has something to do with the size
>> problem I'm encountering ...... I probably wanna know where is it
>> anyway. I don't think I thought to change it from the default
>> setting, as I was new, and still am to what behaviour to expect
>> from Qubes systems ...and just let it back up where-ever the
>> default would be.
> Yeah, it sound like you probably have ~500GB worth of backups in your
> dom0 home directory. You'll probably want to move those to another
> location before backing up dom0 (if you don't want to include those
> backups in your backup).
>> PS: keeping in mind, my perhaps, *only reason to be attempting a
>> backup would be to migrate it to 4.0  ,
> I recommend making frequent backups (so that you don't lose data in an
> unexpected hardware or software malfunction), not just for migration.
>> so I  *still want to back up Templates and Dom0??
> That really depends on you. The answer will be different for different
> people. The main consideration is whether you have any data in dom0's
> home or in your TemplateVMs that you don't want to lose. Personally, I
> would back everything up just in case. You may not end up using it all
> in the migration process, but the problem is that you may not be
> entirely certain, before that process is complete, which data you will
> want to have migrated. In hindsight, you may wish you had migrated
> more. You can always exclude data you have, but you can't include data
> you no longer have.
>> Most of my AppVMs are just for browsing the web and the 15
>> different times, I've reset up  firefox with perhaps a few
>> downloads ..... considering that would there be some reason to
>> backup AppVMs .....
>> Maybe the only VM that matters *is the 300GB AppVM with photos in
>> it , that stays offline ?
> Again, it really just depends on what data you want to keep. Given
> your uncertainty, I highly recommend backing up *everything* so that
> you don't regret losing something later. It sounds like you're talking
> about less than a terabyte in total, which is a pretty small amount of
> data relative to hard drive capacities these days. Better safe than
> sorry!
>> re: /var/tmp  is  dom0  I am unable  to  cut and paste  from  dom0
>> what I see is /dev/mapper/qubes_dom0-root  952848292
>> 780151168(used) 123272164(available) 87%   / and various others
>> smaller directories   ; I don't know what a "partial restore"
>> would look like ; I never touch dom0         :0
> It would be some large directories in /var/tmp that start with
> `restore_`. But it sounds like that's not your problem. Pretty sure
> it's what we diagnosed above (large backups in dom0 home).
> - -- 
> Andrew David Wong (Axon)

And *Once something is in dom0  files  it can't be moved *out to any
other VMs , so guess I need to  delete the  large  AppVM backup, that is
*indeed in dom0 /home   and re-back it up to an another internal HD ....
would seem to be preferable , that backing up to dom0 to dom0  (since I
guess I'll be backing up "everything" and if that's too large then maybe
I'll skip the Templates...

But, again just curious,  are the Templates , Whonix, and AppVMs, dom0  
going to be *importable   into   Qubes 4.0  ?  in general , I don't
really use Deb-8  which it sounds like will be in Q4.0, and Fedora's
Templates will be F26  *not F25 ....... ?

PS: cc "user list"

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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to