[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Baldur Norddahl
Subject: Re: [rdiff-backup-users] Backup of changing files
Date: Wed, 04 Apr 2007 15:07:54 +0200
User-agent: Thunderbird (Windows/20070221)

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.


dean gaudet skrev:
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 that rdiff/rsync on a changing file produces a new file which potentially never existed at any point in time.

anyhow if you send a patch to ignore this error i'll apply it

reply via email to

[Prev in Thread] Current Thread [Next in Thread]