On Fri, Jan 07, 2011 at 10:25:05AM +0000, Mister IT Guru wrote:
> On 07/01/2011 09:59, Graham Keeling wrote:
> > On Fri, Jan 07, 2011 at 09:53:27AM +0000, Mister IT Guru wrote:
> >> 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?
> > He was confused. A VirtualFull will create a new backup, which may involve
> > creating a new volume.
> >
> Thank you for the clarification! That's what I thought before hand. 
> *phew* otherwise my backup plans would be fubard! Why do you say, "may 
> involve" creating a new volume?

Because, depending on what bacula feels like doing, it may append to or recycle
an existing volume.

> I'm thinking of having a separate pool for Virtual Backups, that I will 
> rsync offsite. Will these backups be viable? If my virtual backups are 
> mixed in with my regular backups, for me, that becomes way too much to 
> be syncing offsite constantly.

The VirtualFulls will be viable backups.
Once they have finished, they are almost indistinguishable from normal Fulls.
Even the 'Level' field in the database says 'F', rather than 'V' or something
like that.

> At least if my VirtualFulls are only really Diffs, I know that I'm 
> syncing the minimum amount of data off site so that I can recover in the 
> event of a full system failure. If I'm walking into a false sense of 
> security, please, someone stop me!

Unless somebody knows better, I don't think rsync can help you, because all
the files will be written fresh to a new location (a new volume, appended to
an existing volume, or overwriting an existing volume), and rsync will then
have to send the whole lot.


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