risks of backup using filesystem snapshot/dump ?

From: Jim Mercer <jim(at)reptiles(dot)org>
To: pgsql-admin(at)postgresql(dot)org
Subject: risks of backup using filesystem snapshot/dump ?
Date: 2013-04-06 16:40:27
Message-ID: 20130406164027.GU24874@reptiles.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

hi,

i'm running pgsql 9.1.3 (soon to be upgraded to 9.2.x) on FreeBSD 8-STABLE.

i've got a db of some 550GB that i want to backup on a daily basis, as we
have had some nasty hardware/power/other issues of late.

with dump on FreeBSD, you can specify -L, which does a filesystem level
snapshot before the dump starts, and then clears it afterwards.

i did a backup using dump on the filesystems, except for $PGDATA, followed
by a pg_dumpall.
this took 4 hours, and ate some 30GB (after compression)

i'm currently doing a dump of the filesystems, including $PGDATA.
this is looking like it will take 6-7 hours, and looks like it will take
some 40-50GB (after compression)

if i were to attempt a restore by replaying the 'pg_dumpall', i suspect that
i would be looking at many hours, and possibly hiccups requiring re-runs, etc.

i'm alot more comfortable with the idea of just restoring the filesystem
dump.

so, the question becomes, if i restore a filesystem snapshot backup, the
DB will be in a 'crashed' state.

what, if any, risks are there with regards to corruption, or the inability to
actually use the restored DB?

--
Jim Mercer Reptilian Research jim(at)reptiles(dot)org +1 416 410-5633
"He who dies with the most toys is nonetheless dead"

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Jim Mercer 2013-04-06 16:46:05 purpose/use of pg_start_backup() pg_stop_backup()
Previous Message Bruce Hunsaker 2013-04-05 17:40:47 Re: Trouble connecting locally after 9.2.4 upgrade