On 07/01/2011 10:41, Graham Keeling wrote:
> 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.
Ah, because any full backup copies everything anyway, so any new volumes 
created will be the full dataset anyway. I suppose it's good for 
transferring backups on disk to tape - For example taking monthly 
backups - you know with 100% certainty, that your carrying a credible 
full backup. Hmm.... I think I have to rethink my backup strategy.

------------------------------------------------------------------------------
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