Re: [rdiff-backup-users] Backup of changing files

[Jim C. Nasby]

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 gibberish. It is only important that the non changed blocks 
> are preserved.
> 
> When the database changes a block, it will also write in a separate file 
> "I changed block X to data Y". Those are the journal log files.
> 
> By using those log files, the database will rewrite all the changed 
> blocks and discard whatever data the copy process put into those places.
> 
> Realize that no matter what copy method you use (except for the LVM 
> instant mirror method), you will end up with a new file that never 
> existed at any point in time. PITR is designed to recover from that 
> exact situation.
> 
> But since there apparently is no hidden option that can enable 
> rdiff-backup to do this, I am going to use the simple solution and copy 
> the files to a temporary location before running rdiff-backup.

Make sure and remember to do pg_start_backup and pg_stop_backup.

BTW, I wouldn't trust what I think you were proposing before. PITR is
designed with the intention that the base backup is complete when
pg_stop_backup is called; it could well get confused if you then
attempted to use a newer base backup. I'm not saying it *would*, only
that it *could*. Even if it worked now, it'd be unsupported, so it could
break later on.

To be honest, I'd recommend just excluding PostgreSQL from your rdiff
setup entirely and just using PITR to handle the backups.
-- 
Jim C. Nasby, Database Architect                address@hidden 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"