Re: Backup procedure

Поиск
Список
Период
Сортировка
От Murthy Kambhampaty
Тема Re: Backup procedure
Дата
Msg-id 2D92FEBFD3BE1346A6C397223A8DD3FC0923A6@THOR.goeci.com
обсуждение исходный текст
Ответ на Backup procedure  ("Enio Schutt Junior" <enio@pmpf.rs.gov.br>)
Список pgsql-admin
I think its fair to say that the documentation is outdated on this subject,
becuase it had in mind a different definition of "consistent snapshots".
See:
http://marc.theaimsgroup.com/?l=postgresql-admin&w=2&r=1&s=LVM+snapshots&q=b
where Tom Lane and Peter Eisentraut agree that if your hardware or software
can copy the data and log files from a given instant in time, you have a
consistent backup. (In that thread, you can even see examples for the
postmaster logs at startup with the backup data. ) Bruce Momjian makes the
same point earlier in this thread as well.

Note that the way to recover data from filesystem level backup is to start a
postmaster on the backup copy of the $PGDATA cluster, dump from the backup
and restore into the "production" databases. (Piping this will avoid having
to create dump files to restore from.) You can't simply copy files around to
recover data from backup.

The bottom line is that if you want backups that are as reliable as pgdump-s
(the gold standard), you can get them off of filesystem snapshots.
Filesystem snapshots are a lot faster than pgdump-s.

Cheers,
    Murthy


-----Original Message-----
From: Enio Schutt Junior [mailto:enio@pmpf.rs.gov.br]
Sent: Wednesday, August 13, 2003 13:12
To: pgsql-admin@postgresql.org
Subject: [ADMIN] Backup procedure


Hi,

According to some answers about the consistency of a database in a snapshot
of a whole
HD (excluding proc, tmp, and dev, of course) and without stopping the
postmaster service,
it is said it should work because it's like if the system has crashed, so
restoring files from
the HD and starting the server would be ok.

According to postgresql administrator's guide, section 9.2 (File system
level backup),
item #1: "The database server *must* be shutdown in order to get a usable
backup. Half-way
measures such as disallowing all connections will not work as there is
always some buffering
going on. For this reason it is also not advisable to trust file systems
that claim to support
"consistent snapshots" ".

Assuming the admin's guide is a "little bit more" right, my backup restore
procedure would
be as follows:

1-Restore data from the backup Hd into a new Hd.
2-Copy some files from /usr/local/pgsql/data like postgresql.conf,
pg_hba.conf, pg_ident.conf,
and some other authentication files whose names appear in pg_hba.conf (I
suspect PG_VERSION and
postmaster.opts would not be needed as initdb should create these files) to
another directory.
3-Remove the entire /usr/local/pgsql/data directory
4-Run initdb -D "/usr/local/pgsql/data"
5-Copy those files back to /usr/local/pgsql/data
6-Start the server
7-Restore information generated by pg_dump (tables) and pg_dumpall -g (users
and groups)

Would this work well? I know there are other procedures and I would be
pleased to know that
this procedure works fine.

Thanks in advance,
Enio

В списке pgsql-admin по дате отправления:

Предыдущее
От: Rod Taylor
Дата:
Сообщение: Re: Why table has drop, but the foreign key still there?
Следующее
От: Murthy Kambhampaty
Дата:
Сообщение: Re: Backup routine