Re: [rdiff-backup-users] Filechange during backup

[Rainer Zocholl]

address@hidden(Neil)  07.01.05 10:55

>one good workaround if you can is to use and lvm snapshot
>you take a snapshot and back that up then remove the snapshot

>http://www.tldp.org/HOWTO/LVM-HOWTO/snapshotintro.html

Wouldn't that double the space requirements?

The LVM-snapshot documentation is always talking about
"a copy of the data". I did not find any hints
how the snapshot feature is really working/implemented.

That sounds to me as the "snapshot" is just a "dd",
which needs a long time to process and only ensures 
"stability" while reading the copy.
Is that true?
Where is it decscripted?

What happens if you have 2 files, say a database and an index.
Making the snapshot may need 10 minutes.
What if the index is already stored in the first minute but 
in the 5th minute a change in the database is done which causes
an rebuilt of the index? In 7th minute the database will
be copied, and, oops, the index file already stored will not fit
anymore!


I know that there are snapshot file systems.
But the don't copy all the data but only the directory structures
meta intos, like a journaling filesystem.
So they are very fast and aware of changes during
the very short time the snapshot needs. Too they only need 
to store the changed data fractions. (hm, where did i read 
that recently? ;-))





>Neil

>On Friday 07 January 2005 10:31, Olav Langeland wrote:
>> Hi,
>>
>> from the rdiff-backup error policy:
>> "These are usually caused by a file being modified as rdiff-backup
>> is processing it. The error log calls these UpdateErrors.
>> When this type of error occurs, rdiff-backup will pretend that the
>> file is the same as it is in the destination directory. For an
>> incremental backup, this means that no new increment will be
>> written, and the mirror copy will not be updated."
>>
>> Found this out when I tried to backup web- and maillogs. 

With "extended attributes" log fles can/should be set
"append only".
That may reduce the problem.


>> Any
>> workaround for it? Not counting rotating logs before backup or
>> making a separate scp command for logfiles. 

That seems to be the only clean way, or?

>> I would be happy with
>> something that makes rdiff-backup ignore filesize changing during
>> backup and just copy the file :)
>>
>> Any help appreciated.
>>
>> Regards
>> Olav Langeland
>>
Rainer---<=====>                         Vertraulich
             //
           //                              
         <=====>--------------ocholl, Kiel, Germany ------------