Re: [GENERAL] VM-Ware Backup of VM safe?

On Wed, 20 Sep 2017 20:24:05 +0200, "Klaus P. Pieper"
<kpi6288@gmail.com> wrote:

>> Von: pgsql-general-owner@postgresql.org [mailto:pgsql-general-
>> owner@postgresql.org] Im Auftrag von George Neuner
>>
>> But VSS is needed only to copy VM files *while* they are in
>> use.  If you snapshot the VM, the snapshot files then are read-only
>> and can be freely copied.  As long as the backup avoids the 
>> currently active files, there is no danger.
>
>But if you take a snapshot without VSS writer functions, I tend 
>to believe that there is a serious potential that relevant 
>information is still only in RAM and not written to disk. This
> would get lost in the snapshot.

I can't speak for all VM managers, but Vmware's standard static
snapshots *do* capture both the memory and power states of the
machine.  If a snapshot is taken while a machine is running,
restarting from that snapshot is the same as if the machine woke up
from suspension.


>I may be wrong, but my understanding of a VSS writer is that all
>transaction and log files are flushed to disk prior tot he snapshot.

You understanding is correct - but I think you are maybe misapplying
it to this case.  VSS operates in the *host*, not in the virtual
machine.  And VSS is purely a Windows mechanism - it does not apply in
Unix or Linux.

VSS is a protocol to enable backing up open application files without
disruptions like share locks.  A backup program can request an aware
application to produce demand snapshots of its open files.  The backup
then copies the snapshots while the application continues to use the
original files.  VSS snapshots themselves are ephemeral: they are
unnamed temporary files that are deleted when closed.


In principle, a VM manager could respond to a VSS request by signaling
aware applications in running VMs to dump state (if relevant).  But
that would only make a VSS snapshot of the machine's "disk" a little
more up to date than one taken statically via the standard mechanism.
And it requires that applications running in the VM, under whatever
guest OS, know how to catch and respond to the VM manager's signal.

In reality, the VSS aware VM managers I know of [including Vmware]
don't do that.  Instead, when requested by backup, they simply take ar
standard snapshot of each running machine.  But instead of saving the
snapshots statically, they create VSS ephemeral snapshots that
disappear when the backup is finished with them.


The long-winded point is that you don't need VSS unless your host is
running Windows, you want to backup machines while they are running,
and you want the backups to be as "fresh" as possible.


Bringing this discussion back to Postgresql, there is no difference
between restoring your database from a saved backup vs rolling back
the virtual machine running Postgresql to a saved snapshot.  The end
result is you have lost whatever was done after the save point.


If you are happy with your VM manager's standard snapshots, there is
no need for additional complexity.  My point initially was simply that
the VM manager's snapshot mechanism saves a disk image, which will
just as happily preserve a damaged disk as a good one.

To be safe(st) I think it's smart to back up your databases using
Postgresql's own mechanisms in addition to backing up your VMs.


George



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general