I too want to thank all for the feedback as it has made the manual
much clearer to me. I also apologize for apparently muddying the waters
that I did not intentionally mean to do and deter from Mr. Bergen's
original question.
Regards
-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of dbergen
Sent: Friday, February 22, 2008 12:10 AM
To: VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Question about synthetic backups
Thanks for all the feedback, see some more replies below.
> We disagree on what a true synthetic backup is and how it is
implemented.
No, we don't disagree at all, I wasn't stating opinion, I was just
saying how Netbackup handles a synthetic.
> If all you are looking for is another copy of the full backup you
have, then just run
>
> bpduplicate -dp <destination_pool_name> -backupid <backup_id>
>
>
Yes, I can do that easily enough but how do I automatically schedule
such an action (without a Vault license)?
> As to TOP's question, have you tried running a full, then a series of
> incrementals, THEN a syn full or cumulative incremental? That's what
> it's designed for. Why would you make a syn full from a full? The
> results would be the same a duplication of that same backup, with a
lot
> more work. The use of it without any fulls is pointless enough that
the
> program is probably just barfing and saying "what are you doing? You
> don't have any incrementals to merge into a full! All you have is a
> full! Why don't you just copy it?"
>
I understand what you are saying here, my question is about the logic of
WHY it worked that way. The way it is is how I already understood it to
work. What I am trying to say (obviously poorly) is that if I:
1. Make a FULL synth to the onsite tape pool.
2. Want another FULL from the same time written to the offsite tape pool
at a later date but BEFORE another incremental has taken place, I can't
seem to do it, other than with Vault.
What I was trying to get an answer to is... Shouldn't Netbackup be smart
enough to say "he is requesting another FULL, I just did one, BUT I see
this one is to a different media pool so I will copy the most current
full to the media pool as requested"
> In order to create a Synthetic Full/Cumulative backup, NBU wants to
have
> on tape all of the files in the condition they currently exist on the
> client being backed up. In order to do that, it must perform an
> incremental. Otherwise you'd be creating a full backup based on files
> that were backed up at some previous point in time, so your synthetic
> backup would look like it was taken yesterday or before. Therefore,
NBU
> requires you to take an incremental just before.
>
Hmm... maybe things have changed in 6.5.1 as it doesn't require an
incremental backup just before at all. You are free to make the
synthetic at any time after the incremental, just with the understanding
that your synth full will only be as current as you most recent
incremental.
> He's incorrectly (I believe) assuming that the Synthetic backup picks
up
> differential information from the client, in the process of creating
the
> Synthetic Full.
>
No, I understand how the synthetic works.
> And RTFM is what the
> original poster could have done rather than complain that NetBackup
> doesn't work like TSM.
>
Huh? I never said anything of the sort and I HAVE read the manual, quite
a bit of it actually.
> Or whenever; there is no need for immediacy other than the synthetic
> full (or synthetic cumulative) is only as current as the latest
> incremental it uses. That's obvious, but I need to remind myself
> periocially that I can schedule the synthetic when resources are
> available rather than right after the last incremental component.
Exactly, unlike what Chris said above this is one of the big pluses to
Synthetics for me, I can generate the weekly full anytime over the next
3-4 days.
Thanks everyone for the feedback, I will be changing one datacentre to
almost totally synthetic backups next month and this is more great info.
thanks,
dbergen
+----------------------------------------------------------------------
|This was sent by dbergen AT cucbc DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
