qvm-backup - what should be included in a backup?

[Zrubecz Laszlo]

Hi,

I saw the huge thread about the backup procedure in details, but I
missing some important things from the actual backups:

- current template
Not found any way to backup the current template (just ended up with a
simple cp to keep my updated and customized template)

- DVM customization
Still not sure what should I backup to keep these changes...

- system wide settings
I know these are system specific configs, but at least /etc/qubes* is
need to be backed up.


--
Zrubi

[Olivier Médoc]

On 08/28/13 23:33, Zrubecz Laszlo wrote:
> Hi,
>
> I saw the huge thread about the backup procedure in details, but I
> missing some important things from the actual backups:
>
> - current template
> Not found any way to backup the current template (just ended up with a
> simple cp to keep my updated and customized template)

The backup system does not backup the fedora-18-x64 template, but it
will backup other templates. You can clone your template to a new name
and use this new template instead.

I think the idea behind that is that the backup fedora-18-x64 is managed
by rpm and is replaced if the qubes teams upload a new template version
(eg: for major fedora upgrades such as fedora 18 -> fedora 19, mostly
because of a new Qubes release).

> - DVM customization
> Still not sure what should I backup to keep these changes...
>
> - system wide settings
> I know these are system specific configs, but at least /etc/qubes* is
> need to be backed up.

That is a good point. The dom0 home is backuped (so that you keep your
GUI settings...), but I don't think the dom0 /etc directory is backuped.

[Joanna Rutkowska]

On 08/29/13 09:54, � wrote:
> On 08/28/13 23:33, Zrubecz Laszlo wrote:
>> Hi,
>>
>> I saw the huge thread about the backup procedure in details, but I
>> missing some important things from the actual backups:
>>
>> - current template
>> Not found any way to backup the current template (just ended up with a
>> simple cp to keep my updated and customized template)
> The backup system does not backup the fedora-18-x64 template, but it
> will backup other templates. You can clone your template to a new name
> and use this new template instead.
>
> I think the idea behind that is that the backup fedora-18-x64 is managed
> by rpm and is replaced if the qubes teams upload a new template version
> (eg: for major fedora upgrades such as fedora 18 -> fedora 19, mostly
> because of a new Qubes release).
>

Yes, exactly. However, I agree that we should have an automatic
mechanism for preserving the modifications that the user did to the
default template -- at the very least an easy way to later automatically
install/remove a set of rpms, that the user decided to install/remove.
The easiest way of doing this would be to save a list of rpms
added/removed by the user, and just "reply" this list in whatever
default template it is on the system we're restoring the backup. Such
list of added/removed rpms could probably be extracted using the 'yum
history' command, or alternatively by having the list of rpms of the
original template (rpm -qa > /etc/template_original_rpms_list) and
diff'ing it with the current list (rpm -qa > template_current_rpms_list).

Something to do in the future I guess :)

>> - DVM customization
>> Still not sure what should I backup to keep these changes...
>>

Customizations like what?

>> - system wide settings
>> I know these are system specific configs, but at least /etc/qubes* is
>> need to be backed up.
> That is a good point. The dom0 home is backuped (so that you keep your
> GUI settings...), but I don't think the dom0 /etc directory is backuped.
>
>

Agree.

joanna.

[Zrubecz Laszlo]

On 29 August 2013 10:00, Joanna Rutkowska <joa...@invisiblethingslab.com> wrote:
> On 08/29/13 09:54, � wrote:
>> On 08/28/13 23:33, Zrubecz Laszlo wrote:

>>> I saw the huge thread about the backup procedure in details, but I
>>> missing some important things from the actual backups:
>>>
>>> - current template
>>> Not found any way to backup the current template (just ended up with a
>>> simple cp to keep my updated and customized template)
>> The backup system does not backup the fedora-18-x64 template, but it
>> will backup other templates. You can clone your template to a new name
>> and use this new template instead.
>>
>> I think the idea behind that is that the backup fedora-18-x64 is managed
>> by rpm and is replaced if the qubes teams upload a new template version
>> (eg: for major fedora upgrades such as fedora 18 -> fedora 19, mostly
>> because of a new Qubes release).
>>
> Yes, exactly. However, I agree that we should have an automatic
> mechanism for preserving the modifications that the user did to the
> default template

I really don't get this point.

The default template delivered from the rpm is just a basic starting point...
After the first update/upgrade it is not the same anymore as come from
the template so it must not be replaced by a dom0 update ever!

Thats why I would like to see it in the backups and never bothered by
cloning it.

Trying to recreate the changes is not so simple and meaningless effort.
Actually I made some system wide changes as well not just installed
new applications.

>>> - DVM customization
>>> Still not sure what should I backup to keep these changes...
>
> Customizations like what?

Like default application settings, browser plugins, etc...
http://qubes-os.org/trac/wiki/UserDoc/DispVMCustomization


--
Zrubi

[Axon]

Also, if the default fedora-18-x64 template is supposed to be managed by
rpm and replaced by updates, then it essentially eats ~6GB of the user's
disk space, since the user should not expect to rely on it to save her
potentially security-sensitive changes and therefore should not actually
*use* it. (I.e., the user must instead clone then modify, even if the
changes are minor.) This includes even little security changes that
"should" be there by default, such as NOT showing thumbnail previews of
files in nautilus.* All it takes is one "update" of the
non-user-controlled template that reverts to default insecure behavior
and one malicious file that exploits the preview mechanism (or any other
security-related change you made) for a sensitive AppVM to get compromised.

*I mean "should" from a security standpoint. I'm NOT necessarily saying
that things like this are the responsibility of the Qubes team.