From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Rich Shepard <rshepard(at)appl-ecosys(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Table update: restore or replace? |
Date: | 2019-05-15 00:08:51 |
Message-ID: | 20190515000851.GD6197@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Greetings,
* Rich Shepard (rshepard(at)appl-ecosys(dot)com) wrote:
> That's why I thought of copying the entire data/ directory.
That isn't going to work because things change in the data directory...
> >Also, I don't know what method you've been using to make file-level
> >backups, but they're really pretty worthless unless you (a) stop the
> >server or (b) use a filesystem snapshot. Otherwise you're very likely to
> >have inconsistent data.
>
> I run dirvish <http://www.dirvish.org/> which runs each night starting at
> 00:30 am when there's no activity (by me, at least) on the database.
The database system is potentially doing things though, so this isn't a
backup solution that is reliable. You really should be using a backup
solution that's been specifically written to work with PostgreSQL.
I wouldn't trust performing a restore from a backup taken like this.
I'd suggest you restore to a new server (or another directory, at
least...) and try starting up PG and then dump out the table and then
check that it's valid.
And then switch to a backup system that actually works with PG.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | AYahorau | 2019-05-15 07:04:12 | Re: terminating walsender process due to replication timeout |
Previous Message | Rich Shepard | 2019-05-14 23:35:07 | Re: Table update: restore or replace? [RESOLVED] |