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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
