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

[Baldur Norddahl]

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.

Baldur

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
>