Hi,

On Tue, 08 Dec 2009, Niklas Hagman - FiberDirekt AB wrote:

> Hi there Gavin. Thanks for the answer.
> It seems like I have misunderstood something here.
> 
> You say that it only requires about 1.4GB more disk space to have
> F+I+I+I+I+I+I+I+I+I+I+I+I+I+F2+I2+I2+I2+I2+I2+I2+I2+I2+I2+I2+I2+I2+I2
> where F2 is a VirtualFull backup.

What I mean is that if you go your suggested route of VirtualFull backups,
you're going to need (at minimum) enough space to store two full backups
and a fortnight of incrementals.

With the simpler approach of just running a normal full backup every
fortnight and recycling them, you would need the same.  All you'll need
extra, is another fortnight of incrementals.  

Ignoring compression, you'll need 

        287GB*2 + 100MB*14 
                vs
        287GB*2 + 100MB*14 + 100MB*14

which is a minimal extra space cost but in return you get a simple approach
that won't leave anyone scratching their head.

> Do you mean that a Virtual Backup does not take up more space on the
> disk? It's just a catalog entry? That's really great if it's true!
> I thought that one Full and one VirtualFull will take up 287GB*2 in space.

(As I understand it) A virtualfull, once done looks exactly like a full
backup.  The difference is just in how it was created.

To me, the benefit of virtual full backups is in not having to load the
live server to create a full backup.  I don't believe it saves space
particularly.

Gavin


------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users