On Wed, Apr 04, 2007 at 03:07:54PM +0200, Baldur Norddahl wrote:
Postgresql files are divided into 8 KB blocks. During the time it takes
to do the copy, a number of blocks will have changed. What happens to
those changed blocks is irrelevant - they can be old data, new data or
just random
On Fri, 30 Mar 2007, Baldur Norddahl wrote:
I want to use rdiff-backup with my Postgresql database. The problem is that
the tool refuses to backup files that are changing.
We simply pg_dumpall /backup/sqldump.sql and then rdiff-backup the
/backup directory. Then you don't have to worry
Postgresql files are divided into 8 KB blocks. During the time it takes
to do the copy, a number of blocks will have changed. What happens to
those changed blocks is irrelevant - they can be old data, new data or
just random gibberish. It is only important that the non changed blocks
are
without knowing anything about PITR... have you actually tried restoring
from rsyncs in this situation? knowing what i do about the rdiff/rsync
algo i'm having a hard time imagining any such feature truly working over
*all* differences. i can imagine how PITR works, and the problem i see is
Baldur Norddahl wrote:
I am aware of an earlier thread on this mail list, which proposes
using LVM for freezing the source while doing the backup. This will
indeed work for my purpose, but will require extensively
reconfiguration of my setup and should be unnecessary. Even using LVM,
my
Hi,
I want to use rdiff-backup with my Postgresql database. The problem is
that the tool refuses to backup files that are changing.
The database is live and modifying the database files during the backup.
This is fine, because I am using the PITR (point in time recovery)
feature of
Baldur Norddahl wrote:
Hi,
I want to use rdiff-backup with my Postgresql database. The problem is
that the tool refuses to backup files that are changing.
The database is live and modifying the database files during the
backup. This is fine, because I am using the PITR (point in time
