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