0

Quick question about snapshot backups. I have a hobby project at home where I have a webapp connected to a postgresdb on a VM. I want a simple way to do backups so I wrote a script which stops the postgres service, snapshots the VM, and then starts the service again. I know the webapp doesn't work during this period which is expected but still have the following questions:

1) Apart from installing some sort of agent to manage the database for backups, is this a reasonable way to reliably backup the system?

2) Are there any issues I should be aware of when using a method like this?

Edit: I have software which then takes the snapshot and stores it off of the devices, stores the past several, and I've verified the snapshot comes back in a different vCenter environment.

3
  • You haven't backed it up, you've only taken a snapshot. Apr 1, 2016 at 19:56
  • @ChrisInEdmonton Thanks for catching that, I added an edit - the snapshot is stored outside of the ESXi host and able to be imported in to another successfully.
    – Abraxas
    Apr 1, 2016 at 20:34
  • Why are you just not backingup the entire datastore for the virtual machine, that way, you can fall back to it? Doing it daily, weekly, monthly are all good ideas. There are entire sections on the VMWare exam on how to backup the VMs running on a ESXi host
    – Ramhound
    Apr 1, 2016 at 20:35

1 Answer 1

2

Like ChrisInEdmonton pointed out, what you are doing is snapshotting, not backing up.

A backup implies some sort of secondary storage. This can be everything from floppy disks or USB thumbdrives, to a second hard drive (often external), to magnetic tape, to just about anything else. A backup is often stored in a location physically distinct from the data that is being backed up, to protect against "common mode" failures (failures where a single root cause affects multiple devices, such as a power surge taking out both the original as well as the backup).

Additionally, your scheme has a potentially serious problem.

You are snapshotting a running VM. Depending on the OS and utility software (within the VM) involved, this is not at all guaranteed to produce an internally consistent image.

Basically, what you are doing is the same as if you would stop the database server on a physical host, forcibly power off the host, remove the hard drive, and call that a backup. I think we can agree that this isn't a great backup scheme.

Stopping the database server software is a good first step, but it doesn't at all guarantee things like that all OS-level caches have been flushed to persistent storage (from the point of view of the OS running inside the VM).

PostgreSQL comes with a pg_dump utility, which will dump the database to a SQL script that can be fed back into PostgreSQL to rebuild the database. (Make sure to check the man page so that you get all relevant options correct, and as with all backups, test it!) This is convenient, but not necessarily 100% consistent. Depending on your needs, this may be good enough.

Alternatively, you can stop the PostgreSQL server (this ensures that there are no in-flight transactions) and copy its data files to a separate location that is served by a different PostgreSQL instance. Start both, and run pg_dump against the second instance. Once the dump completes, stop the second instance. This is more complex, but virtually guarantees that you get an internally consistent dump without relying on PostgreSQL's data file format remaining unchanged. If the database is large, it should be possibly to copy most files while PostgreSQL is still running and then run something like rsync after stopping PostgreSQL to transfer the delta, to reduce downtime.

The rest of the VM can be backed up using normal means, disregarding the fact that it's a VM. If you are keeping all the volatile data on a separate virtual disk, then it might even be possible to configure most of the system for read-only file system mounting which means a simple copy of the virtual disk image file from outside the VM can be performed with reasonable results even while the VM is running.

2
  • Thanks for the detailed answer. I've edited my question to include the 'backup' step after the snapshot is taken. I use software which takes the snapshot and stores it so it can be imported in to different ESXi/vCenter environments. I am reasonably confident that the application/system are resilient to this type of backup but am uncertain about the database. In particular, I don't know if stopping the Windows Postgresql service is necessarily a safe way to stop activity on the database? I assume it negotiates a time to stop and doesn't just force it to close?
    – Abraxas
    Apr 1, 2016 at 20:36
  • "it doesn't at all guarantee things like that all OS-level caches have been flushed to persistent storage (from the point of view of the OS running inside the VM)." I don't see how that matters. Taking a snapshot of a running VM saves the state of its RAM, CPU registers, etc. As long as the VM isn't actively doing I/O with things external to the VM (e.g. network connections, mounted disks), then the snapshot should be internally consistent.
    – jamesdlin
    Apr 8, 2016 at 2:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .