Steve Costaras wrote:
> 
> On 01/14/2010 15:59, Dan Langille wrote:
>> Steve Costaras wrote:
>>
>>> I see the mtimeonly flag in the fileset options but there are many
>>> caveats about using it as you will miss other files that may have been
>>> copied over that have retained mtimes from before the last backup.
>>> Since bacula does an MD5/SHA1 hash of all files I assumed (wrongly it
>>> seems) that it would be smart enough to not back up files that it
>>> already had backed up and are on tape.
>> Smart enough?  Sheesh.  ;)
>>
>> That hash is to ensure the file is restored properly.  And for 
>> verfication.  To do what you want is not easy.
>>
>> How big of a problem is this for you?
>>
>> Have you looked into the Virtual Backups, although I'm not sure this 
>> would help you.
> 
> :)  Well I figured it would be relatively easy as an option (since the 
> hash is in the database and when a file is read from disk for backup 
> (since it's planning on backing it up anyway it would need to read the 
> file, if the file name & hash match those that are in the database the 
> file could be skipped.   (for 'real' completeness and to keep in line w/ 
> the accurate option perhaps update the database with permissions et al 
> on the inode but since the content matches that would save a lot of tapes).

In the database... not on the client.  That's the issue.  Let us not 
discuss this here.  It is not a trivial problem to do correctly.

> In the case here it's rather a large issue (granted due to other 
> problems like hardware or software issues that require restores of data 
> and is NOT something that I want to continue, however we are living in 
> an imperfect world) but to give you an idea the dataset size is about 
> 30-40TiB with restores anywhere from 2TiB to a full restore to back that 
> back up again not only takes a LOT of tapes which is costly it also 
> takes a LOT of time (day/weeks) where nothing else can be run.
> 
> What I have been doing which is just painful is do a full restore, then 
> have to do a full backup right after then continue so a restore is 
> actually the time of about 2x of a full.  (for a full set this is about 
> 9-10 days on LTO4).   This has happened about 3 times so far in the past 
> 2 months.

I would start a new thread.  How to avoid backing up restored files.

This one has gone its course.

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users