On 06/01/2011 18:47, Phil Stracchino wrote: > On 01/06/11 12:54, Mister IT Guru wrote: >> Okay, I see the point of Virtual Full Backup - this is to be done >> without talking to the client at call, (i did know that! I've been doing >> my homework!) Well, now that I'm looking at the virtual backup in the >> capacity in which it was intended, it seems that a virtual full backup, >> is an amalgamation of the current files stored within bacula. So >> effectively it's a point in time snapshot from when the last >> differential, or incremental finished for that client? > Yes, that's a very good way to look at it. > >> I would still prefer to have the latest files from the client packed >> into this job, but I do understand, that even the very best backups >> really are just a point in time snapshot. Well, I'm a little upset to >> come to this realisation with regards to the theory of it - In practical >> terms, will a virtual full cause a new volume to be created? > No, it should create no new media, as no new data is copied, only new DB > records. > > So a VirtualFull is not just the last full plus all the latest files within bacula, it also doesn't actually exist as media?
So I cannot copy a volume? This means that if I want to take a physical copy of the latest full backup, I will literally have to run a full backup across my entire server farm? ------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users