On Wed, 20 Sep 2017 20:24:05 +0200, "Klaus P. Pieper" <kpi6288@xxxxxxxxx> wrote: >> Von: pgsql-general-owner@xxxxxxxxxxxxxx [mailto:pgsql-general- >> owner@xxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
