Re: [Veritas-bu] Tapeless backup environments?

[A Darren Dunham]

On Wed, Sep 26, 2007 at 05:15:08PM -0400, bob944 wrote:
> Perhaps anything can have a failure mode where it doesn't alert--but in
> a previous lifetime in hardware and some design, I saw only one
> undetected data transformation that did not crash or in some way cause
> obvious problems (intermittent gate in a mainframe adder that didn't
> affect any instructions used by the OS).  

There's a lot more data out there now (more chances for problems).
Disk firmware has become much more complex.

> I don't remember a disk that didn't maintain, compare and _use for error
> detection_, the cylinder, head and sector numbers in the format.  

Disks may (usually) do that, but they don't report it back to you so you
can verify, and they're not perfect.

One of the ZFS developers wrote about a disk firmware bug they
uncovered.  Every once in a while the disk would return the data not
from the requested block but from a block with some odd calculated
offset from that one.  Unless the array/controller/system is checking
the data, you'll never know until it hits something critical.

Netapp also talks about the stuff they had to add because of silently
dropped writes and corrupted reads.

Everything has an error rate.  

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://www.taos.com/
Got some Dr Pepper?   San Francisco, CA bay area
 < This line left intentionally blank to confuse you. >
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 6.5 or 6.0MP5

[Ed Wilts]

2 weeks according to Aptare.

Bocada used to access the data as a media server whereas Aptare accesses the
data via command-line utilities.  That should make it easier for Aptare but
of course they still have to update their code to take into account changes
in the command-line tools.  If not sure if all of the tools they use are
even supported by Symantec and we've already heard of some commands going in
6.5 (like bpdir which StorageConsole doesn't have a reason to use).

.../Ed

--
Ed Wilts, RHCE, BCFP, BCSD
Mounds View, MN, USA
mailto:[EMAIL PROTECTED]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:veritas-bu-
> [EMAIL PROTECTED] On Behalf Of Dyck, Jonathan
> Sent: Wednesday, September 26, 2007 8:34 AM
> To: Veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] NBU 6.5 or 6.0MP5
> 
> Any report on this for Aptare anyone?
> 
> Thanks,
> Jon
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Cruice,
> Daniel (US - Glen Mills)
> Sent: Wednesday, September 26, 2007 8:21 AM
> To: A Darren Dunham; Veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] NBU 6.5 or 6.0MP5
> 
> As far as the reporting tools, NBU 6.5 will break Bocada.  Not sure
> why,
> but we had Bocada in here last week discussing our options, and they
> simply said "Bocada will break".  And they would not give us a ETA as
> to
> when they will have NBU 6.5 support for Bocada.  But they did say they
> are working on it.
> 
> Thanks
> Dan
> 
> -Original Message-
> From: A Darren Dunham [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 25, 2007 6:37 PM
> To: Veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] NBU 6.5 or 6.0MP5
> 
> On Tue, Sep 25, 2007 at 04:58:02PM -0400, Preston, Douglas L wrote:
> > As far as I am concerned 6.5 is better.  I have had far less issues
> with
> > it that I did with any 6.0 MP#.  If you have any reporting software
> it
> 
> > will break it.
> 
> Do you know the mechanism of this breakage?  Do some of the tools
> change
> output or something?
> 
> --
> Darren Dunham
> [EMAIL PROTECTED]
> Senior Technical Consultant TAOS
> http://www.taos.com/
> Got some Dr Pepper?   San Francisco, CA bay
> area
>  < This line left intentionally blank to confuse you. >
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 
> This message (including any attachments) contains confidential
> information intended for a specific individual and purpose, and is
> protected by law. If you are not the intended recipient, you should
> delete this message and are hereby notified that any disclosure,
> copying, or distribution of this message, or the taking of any action
> based on it, is strictly prohibited.
> 
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 
>  This message may contain privileged and/or confidential
> information.  If you have received this e-mail in error or are not the
> intended recipient, you may not use, copy, disseminate or distribute
> it; do not open any attachments, delete it immediately from your system
> and notify the sender promptly by e-mail that you have done so.  Thank
> you.
> 
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] How to backup 30TB of data

[Patrick]

Does the 30TB of data change daily? If it is normal data that changes at a
reasonable rate why not bite the bullet once and then do synthetic fulls there
after?

Regards,

Patrick Whelan
[EMAIL PROTECTED]
VERITAS Certified NetBackup Support Engineer for UNIX 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of King5899
Sent: Wednesday, September 26, 2007 8:29 PM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] How to backup 30TB of data


This solution is in addition to our existing SAN solution for this customer.
They currently have an EMC CX500 with a Cellerrra front end. Our NDMP backups
over fiber run about 100 GB/hour. For a backup of 30 TB to occur over 60 hours I
don't see how to do it. We proposed an Onstor NAS Gateway as the frontend
runnning NDMP, however we are not sure of the throughput we would see.

Thanks,
MJK

+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Tapeless backup environments?

[bob944]

> On Wed, Sep 26, 2007 at 04:02:49AM -0400, bob944 wrote:
> > Bogus comparison.  In this straw man, that 
> > 1/100,000,000,000,000 read error a) probably doesn't
> > affect anything because of the higher-level RAID array
> > it's in and b) if it does, there's an error, a
> > we-could-not-read-this-data, you-can't-proceed, stop,
> > fail, get-it-from-another-source error--NOT a silent
> > changing of the data from foo to bar on every read
> > with no indication that it isn't the data that
> > was written.
> 
> While I find the "compare only based on hash" a bit annoying
> for other reasons, the argument above doesn't convince me.
> 
> Disks, controllers, and yes RAID arrays can fail silently in
> all sorts of ways by either acknowledging a write that is not
> done, writing to the wrong location, reading from the wrong
> location, or reading blocks where only some of the data came
> from the correct location.  Most RAID systems do not verify
> data on read to protect against silent data errors on the
> storage, only against obvious failures.

Perhaps anything can have a failure mode where it doesn't alert--but in
a previous lifetime in hardware and some design, I saw only one
undetected data transformation that did not crash or in some way cause
obvious problems (intermittent gate in a mainframe adder that didn't
affect any instructions used by the OS).  

I don't remember a disk that didn't maintain, compare and _use for error
detection_, the cylinder, head and sector numbers in the format.  

The write frailties mentioned, if they occur, will fail on read.  And
the read frailties mentioned will generally (homage paid to the
mainframe example I cited as the _only_ one I ever saw that didn't)
cause enough mayhem that apps or data or systems go belly-up in a big
way, fast.  

These events, like double-bit parity errors or EDAC failures, involve
1.  that something breaks in the first place
2.  that it not be reported
3.  that the effects are so subtle that they are unnoticed (the app or
system doesn't crash, the data aren't wildly corrupted, ...)

The problem with checksumming/hashing/fingerprinting is that the
methodology has unavoidable errors designed in, and an implementation
with no add-on logic to prevent or detect them will silently corrupt
data.  That's totally different, IMO.


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Upgrade Netbackup 5.1MP4 to 6.0 - Solaris

[rcarlisle]

Look for a file called
rm /usr/openv/bin/driver/snapct110_x i
if it exists, remove it and try the pkgrm again
 
 
 
Reneé Carlisle 
ServerWare Corporation
 
 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Koping Wang
Sent: Wednesday, September 26, 2007 3:47 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] Upgrade Netbackup 5.1MP4 to 6.0 - Solaris



Hi, 
I am upgrading Netbackup 5.1 MP4 to 6.0. I got a problem: My Netbackup is
running Solaris 9 
When I remove the old VRTSnetbp,  'pkgrm VRTSnetbp'. At the end, I got
"Removal of  partially failed." 
So when I install Netbackup 6.0, I got the following messages: 

--- 
The following old package is currently installed on your 
system and should be removed prior to an upgrade: 

VRTSnetbp 

*** 
It is highly recommended that older packages be removed before doing an 
upgrade. 
*** 

Do you want to exit this script so you can remove packages now? [y,n] (y) 

-- 
Should I just answer "no:, and continue? 

Thanks 
Koping 

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Upgrade Netbackup 5.1MP4 to 6.0 - Solaris

[rcarlisle]

sorry, answer yes and exit the script...don't try and run and install if the
pkg hasn't been removed.  You did do a remove with upgrade, correct?
 
 
 
Reneé Carlisle 
ServerWare Corporation
 

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Koping Wang
Sent: Wednesday, September 26, 2007 3:47 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] Upgrade Netbackup 5.1MP4 to 6.0 - Solaris



Hi, 
I am upgrading Netbackup 5.1 MP4 to 6.0. I got a problem: My Netbackup is
running Solaris 9 
When I remove the old VRTSnetbp,  'pkgrm VRTSnetbp'. At the end, I got
"Removal of  partially failed." 
So when I install Netbackup 6.0, I got the following messages: 

--- 
The following old package is currently installed on your 
system and should be removed prior to an upgrade: 

VRTSnetbp 

*** 
It is highly recommended that older packages be removed before doing an 
upgrade. 
*** 

Do you want to exit this script so you can remove packages now? [y,n] (y) 

-- 
Should I just answer "no:, and continue? 

Thanks 
Koping 

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Upgrade Netbackup 5.1MP4 to 6.0 - Solaris

[Koping Wang]

All right, After I send the last email, I found this article, it fix my
problem.
http://seer.entsupport.symantec.com/docs/289055.htm

Thanks
Koping


> _ 
> From: Koping Wang  
> Sent: Wednesday, September 26, 2007 12:47 PM
> To:   'veritas-bu@mailman.eng.auburn.edu'
> Subject:  Upgrade Netbackup 5.1MP4 to 6.0 - Solaris
> 
> Hi,
> I am upgrading Netbackup 5.1 MP4 to 6.0. I got a problem: My Netbackup
> is running Solaris 9
> When I remove the old VRTSnetbp,  'pkgrm VRTSnetbp'. At the end, I got
> "Removal of  partially failed."
> So when I install Netbackup 6.0, I got the following messages:
> --
> -
> The following old package is currently installed on your
> system and should be removed prior to an upgrade:
> 
> VRTSnetbp
> 
> **
> *
> It is highly recommended that older packages be removed before doing
> an
> upgrade.
> **
> *
> 
> Do you want to exit this script so you can remove packages now? [y,n]
> (y)
> --
> 
> Should I just answer "no:, and continue? 
> 
> Thanks
> Koping
> 
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Tapeless backup environments?

[bob944]

> Pls read my other post about the odds of this happening.  
> With a decent
> key space, the odds of a hash collision with a 160=bit key 
> space are so
> small that any statistician would call them zero.  1 in 2^160.  Do you
> know how big that number is?  It's a whole lot bigger than it looks.
> And those odds are significantly better than the odds that you would
> write a bad block of data to a regular disk drive and never know it.

I did read your other post, and addressed your numbers.  C Freemantle
makes the same point I do, perhaps more clearly, in his "birthday
paradox" posting.


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Tapeless backup environments?

[bob944]

> Most of this while well documented seems to boil down to the same
> alarmist notion that had people trying to ban cell phones in gas
> stations.  The possibility that something untoward COULD 
> happen does NOT
> mean it WILL happen.  To date I don't know of a single gas pump

I can't speak for car fires, but I can speak for
checksums/hashes/fingerprints mapping to more than one set of data.
It's been demonstrated.  It happens.  It _has_ to happen.  It's the way
these data reductions work, and the reason why it's more convenient to
refer to small hashes of data rather than the full data for many
uses--this has been a programming commonplace since the '50s.  But
programmers know it's not a two-way street:  a set of data generates
only one checksum/hash/fingerprint, but one checksum/hash/fingerprint
maps to more than one set of data.  And that's fine, for a program that
takes this into account (either because it doesn't matter to the
program's logic or a secondary step checks the data).  As a trivial
example, reducing three-bit data to a two-bit checksum means that trying
to go backwards will retrieve the wrong three-bit data 50% of the time.
Bigger hashes and more sophisticated algorithms reduce the number of
times you get the wrong data; they don't eliminate it.

> If odds are so important it seems it would be important to worry about
> the odds that your data center, your offsite storage location and your
> Disaster Recovery site will all be taken out at the same time.

And if it's not important that the data you read may not be what was
written, don't let me stop you.  _The odds are_ that it'll be okay.  

> I also suggest the argument is flawed because it seems to imply that
> only the cksum is stored and no actual the data - it is original
> compressed data AND the cksum that result in the restore - 
> not the cksum alone.

If I get your meaning, you have an incorrect understanding of the
argument--nobody is talking about generating the original data from a
checksum.  As I said in what you quoted (trimmed here), every unique (as
determined by the implementation) "block" of data gets stored, once.  A
data stream is stored as a list of pointers or
checksums/hashes/fingerprints which refer to those common-storage
"blocks".  Any number of data streams will point to the same "block"
when they have it in common, and as many times as that "block" occurs in
their data stream.  To read the data stream later, the list of pointers
tells the implementation what "blocks" to retrieve and send back to the
file reader.  Now, if "foo" and "bar" both reduced to the same
checksum/hash/fingerprint when stored, somebody is going to receive the
wrong data when the stream(s) that had those data are read.  So sorry
about that corrupted payroll master file...


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] Upgrade Netbackup 5.1MP4 to 6.0 - Solaris

[Koping Wang]

Hi,
I am upgrading Netbackup 5.1 MP4 to 6.0. I got a problem: My Netbackup
is running Solaris 9
When I remove the old VRTSnetbp,  'pkgrm VRTSnetbp'. At the end, I got
"Removal of  partially failed."
So when I install Netbackup 6.0, I got the following messages:

---
The following old package is currently installed on your
system and should be removed prior to an upgrade:

VRTSnetbp

***
It is highly recommended that older packages be removed before doing an
upgrade.
***

Do you want to exit this script so you can remove packages now? [y,n]
(y)

--
Should I just answer "no:, and continue? 

Thanks
Koping

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] How to backup 30TB of data

[King5899]

This solution is in addition to our existing SAN solution for this customer. 
They currently have an EMC CX500 with a Cellerrra front end. Our NDMP backups 
over fiber run about 100 GB/hour. For a backup of 30 TB to occur over 60 hours 
I don't see how to do it. We proposed an Onstor NAS Gateway as the frontend 
runnning NDMP, however we are not sure of the throughput we would see.

Thanks,
MJK

+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] "Full" Media

[Mark.Donaldson]

I'd do one tweak to this, you can't depend on TLD library type or this
being a unique string for the vmquery output.  Better to look at field 8
of the vmquery output, the robot number"
 
Change...
 
grep TLD | awk '{print $1}'
 
..to..
 
awk '$8!="-" {print $1}' 
 
...and it'll be more accurate.



From: Liddle, Stuart [mailto:[EMAIL PROTECTED] 
Sent: Saturday, September 22, 2007 1:49 PM
To: Donaldson, Mark - Broomfield, CO; [EMAIL PROTECTED];
veritas-bu@mailman.eng.auburn.edu
Subject: RE: Re: [Veritas-bu] "Full" Media



That's cool and that's exactly what you get from the
/usr/openv/netbackup/bin/goodies/available_media script...PLUS the
output from that script  tells you about whether the tape is in the
library or not which is what Jonathan wanted to know in the first place.
For that you will need to add the following:

 

/usr/openv/netbackup/bin/admincmd/bpmedialist -mlist -l | awk ' { if (
int($15/8)%2 ) {print $1} }' | xargs -i /usr/openv/volmgr/bin/vmquery -m
{} -l |  grep TLD | awk '{print $1}'

 

You can replace "TLD" with whichever library type you might have.

 

--stuart liddle



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, September 21, 2007 9:05 AM
To: [EMAIL PROTECTED]; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] "Full" Media

 

Full media, it's a bit in the status byte.

 

/usr/openv/netbackup/bin/admincmd/bpmedialist -mlist -l | \
   awk ' { if ( int($15/8)%2 ) {print $1} }'

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin,
Jonathan
Sent: Thursday, September 20, 2007 7:40 AM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] "Full" Media

Is there a "media full" flag I can parse via the command line?  I'm
working on a script for a remote site who only wants to remove "full"
media from the box.  I can guestimate based on how much data is on the
media but when NBU gets to the end of a media, does it flag it anywhere?

 

Thanks,

 

-Jonathan

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Netback 6.0 and 6.5 Exchange 2003 mail recovery

[Spearman, David]

Sure it can, if you have done a mailbox backup. Once licenesed you pick
exchange as your policy type. You then have the ability to back up the
entire DB (good for DR etc) or a mailbox ot public folder backup. The
mailbox and public folder backups are granular down to the individual
messages. That's handy but it can take a very long time to get the
backup. That is because nbu has to open each mailbox. Restores are
faster. It does the restore on the fly without messing with the
services.

dds

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jimlksd
Sent: Wednesday, September 26, 2007 1:33 PM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] Netback 6.0 and 6.5 Exchange 2003 mail recovery



Hi David,

Thanks for your replay Can NBU 6.0 also recover a single mail box
back to the exchange server? Does the exchange server have to stop
service to do the single mail box recovery?

Thanks,

Jim Kroening

+--
|This was sent by [EMAIL PROTECTED] via Backup Central. Forward 
|SPAM to [EMAIL PROTECTED]
+--


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] Netback 6.0 and 6.5 Exchange 2003 mail recovery

[jimlksd]

Hi David,

Thanks for your replay Can NBU 6.0 also recover a single mail box back to 
the exchange server? Does the exchange server have to stop service to do the 
single mail box recovery?

Thanks,

Jim Kroening

+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NB 6.5 and vxlogview

[rcarlisle]

Sorry, no ndmp in this 6.5 environment to test for you.  Can you just grab
everything for that day and not just the originator id.  It may give them
more than they need..but at least they would get information.

FYI...6.5 going well at this site as well.  Heavy duty testing with DSSU
units this weekend. 


 
 
Reneé Carlisle 
ServerWare Corporation
 



___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] How to backup 30TB of data

[Justin Piszcz]

On Wed, 26 Sep 2007, Gregory Demilde wrote:

> Snapshoting is nice but you need to think about restores...  in case
> of file servers 99,999% of your restores will be for a couple of
> files.
>
> Only solution is or flashbackup or start to use wilcards (and exclude
> lists) in your backup selections.
>
> Besides always think about the processing power you have. Network
> traffic tends to consume more CPU than FC. And backups tend to use
> everythings that's left.
>
> Greg
> -- 
> Gregory DEMILDE
> Email : [EMAIL PROTECTED]
> GSM : +352 691 915620
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>

Also if you have too many files in your file list with hardlinks, you 
cannot back it up with a 32bit host (Linux kills the bpbkar process at 
3.0gb) due to the 3/1 split.

Justin.
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] How to backup 30TB of data

[Justin Piszcz]

Wow, is your NDMP implementation broken or highly utilized?  I see ~26-30 
MiB/s regularly with NDMP per stream/volume.

Justin.

On Wed, 26 Sep 2007, Martin, Jonathan wrote:

> Yes, but verify speeds before you buy.  I've got 3TB of NDMP Backups
> running at 6MB/sec.  It takes FOREVER.  We're currently backing up the
> data via NFS shares at 20MB/sec until Sun / StorageTek can get their NAS
> NDMP implementation fixed.
>
> -Jonathan
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Liddle,
> Stuart
> Sent: Wednesday, September 26, 2007 10:34 AM
> To: VERITAS-BU@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] How to backup 30TB of data
>
> One wordNDMP.  Forget about doing it in a reasonable amount of time
> using CIFS.
>
> Also, define "reasonable time"?
>
> --stuart
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of King5899
> Sent: Tuesday, September 25, 2007 2:46 PM
> To: VERITAS-BU@mailman.eng.auburn.edu
> Subject: [Veritas-bu] How to backup 30TB of data
>
>
> I have a new customer coming in that has 30 TB of SAN that they want to
> put behind 2 Windows servers acting as a clustered NAS Gateway.(Not my
> idea). The directory structure includes tens of millions of small images
> spread across 10 of millions of directories. Currently they backup their
> windows servers at a rate of about 25 GB an hour, however the data could
> pass over the fiber network to the fiber tape drives. I am entertaining
> SAN snapshots, and backing up the snapshots from the backup server, but
> not sure if that is the best solution.
>
> How would I possibly back this up in a reasonable time?
>
> Any help would be appreciated.
>
> MJK
>
> +--
> |This was sent by [EMAIL PROTECTED] via Backup Central.
> |Forward SPAM to [EMAIL PROTECTED]
> +--
>
>
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 6.5 MP1 - When?!

[Cruice, Daniel \(US - Glen Mills\)]

November

Thanks
Dan

-Original Message-
From: Dmitri Smirnov [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 26, 2007 11:50 AM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] NBU 6.5 MP1 - When?!


Anyone know when MP1 for 6.5 will be published? I believe the latest
message in forums that it was targeted for Aug, 23 - never happened.

Dmitri

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu 
 
This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and is protected by law. If you 
are not the intended recipient, you should delete this message and are hereby 
notified that any disclosure, copying, or distribution of this message, or the 
taking of any action based on it, is strictly prohibited.

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Tapeless backup environments?

[A Darren Dunham]

On Wed, Sep 26, 2007 at 04:22:01PM +0100, Chris Freemantle wrote:
> For our data I would certainly not use de-duping, even if it did work 
> well on image data.

There are different ways of doing deduplication.  Not all of them rely
on hash signature matching to find redundant data.  You should talk with
a particular vendor and see how they accomplish it.

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://www.taos.com/
Got some Dr Pepper?   San Francisco, CA bay area
 < This line left intentionally blank to confuse you. >
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Tapeless backup environments?

[A Darren Dunham]

On Wed, Sep 26, 2007 at 09:58:12AM -0400, Jeff Lightner wrote:
> I also suggest the argument is flawed because it seems to imply that
> only the cksum is stored and no actual the data - it is original
> compressed data AND the cksum that result in the restore - not the cksum
> alone.

It's not that the actual data isn't stored, it's whether or not the
actual data is checked.  Some algorithms search through the hash space,
and if a hit comes up, they assume that the previously stored data is a
match without a comparison.

The original data must always be stored.  Even if it were possible to
run a hash algorithm in reverse quickly, there would be no way to
determine which of various possible input strings was the original.

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://www.taos.com/
Got some Dr Pepper?   San Francisco, CA bay area
 < This line left intentionally blank to confuse you. >
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 6.5 or 6.0MP5

[A Darren Dunham]

On Wed, Sep 26, 2007 at 10:07:03AM -0400, Preston, Douglas L wrote:
> The activity files changed from flat files to a .db file so the
> reporting software can not grab the data. At least it broke Bocada.

Ah, good (for me anyway).  All my scripts use only defined utilities
like bpdbjobs.  Unless the output or flags change, I'm safe.

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://www.taos.com/
Got some Dr Pepper?   San Francisco, CA bay area
 < This line left intentionally blank to confuse you. >
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] How to backup 30TB of data

[Gregory Demilde]

Snapshoting is nice but you need to think about restores...  in case
of file servers 99,999% of your restores will be for a couple of
files.

Only solution is or flashbackup or start to use wilcards (and exclude
lists) in your backup selections.

Besides always think about the processing power you have. Network
traffic tends to consume more CPU than FC. And backups tend to use
everythings that's left.

Greg
-- 
Gregory DEMILDE
Email : [EMAIL PROTECTED]
GSM : +352 691 915620
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] NBU 6.5 MP1 - When?!

[Dmitri Smirnov]

Anyone know when MP1 for 6.5 will be published? I believe the latest
message in forums that it was targeted for Aug, 23 - never happened.

Dmitri

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Tapeless backup environments?

[A Darren Dunham]

On Wed, Sep 26, 2007 at 04:02:49AM -0400, bob944 wrote:
> Bogus comparison.  In this straw man, that 1/100,000,000,000,000 read
> error a) probably doesn't affect anything because of the higher-level
> RAID array it's in and b) if it does, there's an error, a
> we-could-not-read-this-data, you-can't-proceed, stop, fail,
> get-it-from-another-source error--NOT a silent changing of the data from
> foo to bar on every read with no indication that it isn't the data that
> was written.

While I find the "compare only based on hash" a bit annoying for other
reasons, the argument above doesn't convince me.

Disks, controllers, and yes RAID arrays can fail silently in all sorts
of ways by either acknowledging a write that is not done, writing to the
wrong location, reading from the wrong location, or reading blocks where
only some of the data came from the correct location.  Most RAID systems
do not verify data on read to protect against silent data errors on the
storage, only against obvious failures.

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://www.taos.com/
Got some Dr Pepper?   San Francisco, CA bay area
 < This line left intentionally blank to confuse you. >
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 6.5 or 6.0MP5

[Philip McDougal]

I just received a message from Aptare support on this very subject ...


"Phil,

Just spoke to the big boss, he says it should be out in the next two
weeks. It will probably be in the 6.0.25 (or similar) release.

Cheers"


Thanks.
Phil.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dyck,
Jonathan
Sent: Wednesday, September 26, 2007 8:34 AM
To: Veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] NBU 6.5 or 6.0MP5

Any report on this for Aptare anyone?

Thanks,
Jon


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Cruice,
Daniel (US - Glen Mills)
Sent: Wednesday, September 26, 2007 8:21 AM
To: A Darren Dunham; Veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] NBU 6.5 or 6.0MP5

As far as the reporting tools, NBU 6.5 will break Bocada.  Not sure why,
but we had Bocada in here last week discussing our options, and they
simply said "Bocada will break".  And they would not give us a ETA as to
when they will have NBU 6.5 support for Bocada.  But they did say they
are working on it.

Thanks
Dan

-Original Message-
From: A Darren Dunham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 25, 2007 6:37 PM
To: Veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] NBU 6.5 or 6.0MP5

On Tue, Sep 25, 2007 at 04:58:02PM -0400, Preston, Douglas L wrote:
> As far as I am concerned 6.5 is better.  I have had far less issues
with
> it that I did with any 6.0 MP#.  If you have any reporting software it

> will break it.

Do you know the mechanism of this breakage?  Do some of the tools change
output or something?

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://www.taos.com/
Got some Dr Pepper?   San Francisco, CA bay area
 < This line left intentionally blank to confuse you. >
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu 
 
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and is
protected by law. If you are not the intended recipient, you should
delete this message and are hereby notified that any disclosure,
copying, or distribution of this message, or the taking of any action
based on it, is strictly prohibited.

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
 
 This message may contain privileged and/or confidential
information.  If you have received this e-mail in error or are not the
intended recipient, you may not use, copy, disseminate or distribute it;
do not open any attachments, delete it immediately from your system and
notify the sender promptly by e-mail that you have done so.  Thank you.

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

CALAMOS INVESTMENTS CANNOT ACT UPON, AND WILL NOT ACCEPT, ANY TIME-SENSITIVE 
ELECTRONIC MESSAGES, SUCH AS TRANSACTION ORDERS AND FUND TRANSFER INSTRUCTIONS. 
ALSO, FOR YOUR PROTECTION, PLEASE DO NOT SEND ANY IDENTIFYING INFORMATION, SUCH 
AS ACCOUNT NUMBERS OR SOCIAL SECURITY NUMBERS, THROUGH THE INTERNET.

CONFIDENTIALITY NOTICE: This message is intended only for the use of the 
individual or entity to which it is addressed and may contain information that 
is confidential . If the reader of this message is not the intended recipient, 
you are hereby notified that any dissemination, distribution or copying of this 
communication is prohibited. Please notify the sender immediately if this 
message was transmitted in error. Thank you.

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Netback 6.0 and 6.5 Exchange 2003 mail recovery

[Brooks, Jason]

Depends.

In 6.0, you can backup individual mailboxes and restore messages directly.
Slow.

In 6.5 currently, it's only the DB backup.  Restores to a Recovery Storage
Group and Exchange admin goes from there.  But with a future MP for 6.5,
you're supposed to be able to restore individual messages from a DB backup.

Jason

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of jimlksd
> Sent: Tuesday, September 25, 2007 1:30 PM
> To: VERITAS-BU@mailman.eng.auburn.edu
> Subject: [Veritas-bu] Netback 6.0 and 6.5 Exchange 2003 mail recovery
> 
> 
> I have heard the NBU 6.5 can recover a single email to 
> Exchange 2003 server? [Question]
> 
> Can NBU 6.0 do that?
> 
> +-
> -
> |This was sent by [EMAIL PROTECTED] via Backup Central.
> |Forward SPAM to [EMAIL PROTECTED]
> +-
> -
> 
> 
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu 
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 


smime.p7s
Description: S/MIME cryptographic signature
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Netback 6.0 and 6.5 Exchange 2003 mail recovery

[Brooks, Jason]

>From what I've heard, they didn't steal the march; they're the 'beta' arena
for many features that move into NBU. 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Spearman, David
> Sent: Wednesday, September 26, 2007 10:59 AM
> To: VERITAS-BU@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Netback 6.0 and 6.5 Exchange 2003 
> mail recovery
> 
> James,
> 
> NBU has been able to do mailbox level backups for some time 
> now (includes version 6 and before). If you already have a 
> valid exchange client license all you have to do is set the 
> policy up. Careful reading of manual is suggested.
> 
> However it would appear that the code writers for BackupExec 
> have stolen a march on the NBU folks. I am playing around 
> with the BE11d exchange backups now. With it all you need is 
> a full backup of the exchange DB (preferably to dssu) and 
> whatever incrementals you may desire and the code will open 
> up the database backup and let you drill down. So far it 
> seems to be working rather well and it is sure a lot better 
> than the tedious and lengthy mailbox backups offered by nbu. 
> Our sales weenine tells us nbu will be able to do this mid 2008.
> 
> David Spearman
> County of Henrico, Va.
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of jimlksd
> Sent: Tuesday, September 25, 2007 1:30 PM
> To: VERITAS-BU@mailman.eng.auburn.edu
> Subject: [Veritas-bu] Netback 6.0 and 6.5 Exchange 2003 mail recovery
> 
> 
> 
> I have heard the NBU 6.5 can recover a single email to 
> Exchange 2003 server? [Question]
> 
> Can NBU 6.0 do that?
> 
> +-
> -
> |This was sent by [EMAIL PROTECTED] via Backup Central. Forward 
> |SPAM to [EMAIL PROTECTED]
> +-
> -
> 
> 
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu 
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu 
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 


smime.p7s
Description: S/MIME cryptographic signature
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Tapeless backup environments?

[Chris Freemantle]

It's interesting that the probability of any 2 randomly selected hashs 
being the same is quoted, rather than the probability that at least 2 
out of a whole group are the same. That's probably because the minutely 
small chance becomes rather bigger when you consider many hashs. This 
will still be small, but I suspect not as reassuringly small.

To illustrate this consider the 'birthday paradox'. How many people do 
you need in a room to have at least a 50% chance that 2 of them have the 
same birthday? The chance of any 2 randomly chosen people sharing the 
same birthday is 1/365 (neglecting leap years). Thats quite small, so we 
need a lot of people to get a 50% chance, right? Wrong. You need 23 
people. Google for 'birthday paradox' for the simple maths.

For our data I would certainly not use de-duping, even if it did work 
well on image data.


bob944 wrote:
> cpreston:
>>> Simplistically, it checksums the "block" and looks in a table of
>>> checksums-of-"blocks"-that-it-already-stores to see if the identical
>>>  data already lives there.  
>> To what hole do you refer? 
> 
> The idea that N bits of data can unambiguously be represented by fewer
> than N bits.  Anyone who claims to the contrary might as well knock out
> perpetual motion, antigravity and faster-than-light travel while they're
> on a roll.
> 
>> I see one in your simplistic example, but
>> not in what actually happens (which require a much longer technical
>> explanation).
> 
> Hence my introduction that began with "[s]implistically."  But throw in
> all the "much longer technical explanation" you like, any process which
> compares a reduction-of-data to another reduction-of-data will sooner or
> later return "foo" when what was originally stored was "bar."
> 
> 
> cpreston:
>> There are no products in the market that rely solely on a checksum to
>> identify redundant data.  There are a few that rely solely on 
>> a 160-bit
>> hash, which is significantly larger than a checksum (typically 12-16
> 
> No importa.  The length of the checksum/hash/fingerprint and the
> sophistication of its algorithm only affect how frequently--not
> whether--the incorrect answer is generated.
> 
>> [...] The ability to forcibly create a hash collision means 
>> absolutely nothing in the context of deduplication.
> 
> Of course it does.  Most examples in the literature concern storing
> crafted-data-pattern-A ("pay me one dollar") in order for the data to be
> read later as something different ("pay me one million dollars").  It
> can't have escaped your attention that every day, some yahoo crafts
> another buffer-or-stack overflow exploit; some of them are brilliant.
> The notion that the bad guys will never figure out a way to plant a
> silent data-change based on checksum/hash/fingerprint collisions is,
> IMO, naive.
> 
>> What matters is the chance that two
>> random chunks would have a hash collision. With a 128-bit and 160-bit
>> key space, the odds of that happening are 1 in 2128 with MD5, and 1 in
>> 2160 with SHA-1. That's 1038 and 1048, respectively. If you 
> 
> Grasshopper, the wisdom is not in the numbers, it is in remembering that
> HTML will not paste into ASCII well.  But I suspect you mean "one in
> 2^128" or similar.
> 
> Those are impressive, and dare I guess, vendor-supplied, numbers.  And
> they're meaningless.  We do not care about the odds that a particular
> block "the quick brown fox jumps over the lazy dog"
> checksums/hashes/fingerprints to the same value as another particular
> block "now is the time for all good men to come to the aid of their
> party."  Of _course_ that will be astronomically unlikely, and with
> sufficient hand-waving (to quote your article:  the odds of a hash
> collision with two random chunks are roughly
> 1,461,501,637,330,900,000,000,000,000 times greater than the number of
> bytes in the known computing universe") these totally meaningless
> numbers can seem important.
> 
> They're not.  What _is_ important?  To me, it's important that if I read
> back any of the N terrabytes of data I might store this week, I get the
> same data that was written, not a silently changed version because the
> checksum/hash/fingerprint of one block that I wrote collides with
> another cheksum/hash/fingerprint.  I can NOT have that happen to any
> block--in a file clerk's .pst, a directory inode or the finance
> database.  "Probably, it won't happen" is not acceptable.
> 
>> Let's compare those odds with the odds of an unrecoverable 
>> read error on a typical disk--approximately 1 in 100 trillion
> 
> Bogus comparison.  In this straw man, that 1/100,000,000,000,000 read
> error a) probably doesn't affect anything because of the higher-level
> RAID array it's in and b) if it does, there's an error, a
> we-could-not-read-this-data, you-can't-proceed, stop, fail,
> get-it-from-another-source error--NOT a silent changing of the data from
> foo to bar on every read with no indication that it isn't the data that
> was written

Re: [Veritas-bu] Backing up a SAN

[Curtis Preston]

Absolutely.  When talking millions of files, you must be talking
FlashBackup.  That will help more than anything else.

---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ed Wilts
Sent: Tuesday, September 25, 2007 8:30 PM
To: 'Preston, Douglas L'; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Backing up a SAN

> I have 1 master, 1 media and 5 san media servers.  The san media
servers
> are way too stressed during the backup of their millions of small
files

One word:  FlashBackup.
Seriously, this *significantly* reduces the load on the clients.

--
Ed Wilts, RHCE, BCFP, BCSD
Mounds View, MN, USA
mailto:[EMAIL PROTECTED]

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Veritas-bu Digest, Vol 17, Issue 60

[Nick Majeran]

If you do any NDMP backups at all, do *not* go to MP5.  MP5 introduces
a number of nasty bugs.  If you decide to stick with 6.0, wait for MP6
in December (or so they say).

-- nick


I am running NBU 6.0 MP4 on Windows, lookig to upgrade
to 6.0MP5 or 6.5
I was wondering if any of you have any insights on
which is better and/or less painful way to go?
Thx
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Tapeless backup environments?

[Curtis Preston]

Pls read my other post about the odds of this happening.  With a decent
key space, the odds of a hash collision with a 160=bit key space are so
small that any statistician would call them zero.  1 in 2^160.  Do you
know how big that number is?  It's a whole lot bigger than it looks.
And those odds are significantly better than the odds that you would
write a bad block of data to a regular disk drive and never know it.

---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies 

-Original Message-
From: bob944 [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 26, 2007 4:03 AM
To: veritas-bu@mailman.eng.auburn.edu
Cc: Curtis Preston
Subject: RE: [Veritas-bu] Tapeless backup environments?

cpreston:
> >Simplistically, it checksums the "block" and looks in a table of
> >checksums-of-"blocks"-that-it-already-stores to see if the identical
> > data already lives there.  
> 
> To what hole do you refer? 

The idea that N bits of data can unambiguously be represented by fewer
than N bits.  Anyone who claims to the contrary might as well knock out
perpetual motion, antigravity and faster-than-light travel while they're
on a roll.

> I see one in your simplistic example, but
> not in what actually happens (which require a much longer technical
> explanation).

Hence my introduction that began with "[s]implistically."  But throw in
all the "much longer technical explanation" you like, any process which
compares a reduction-of-data to another reduction-of-data will sooner or
later return "foo" when what was originally stored was "bar."


cpreston:
> There are no products in the market that rely solely on a checksum to
> identify redundant data.  There are a few that rely solely on 
> a 160-bit
> hash, which is significantly larger than a checksum (typically 12-16

No importa.  The length of the checksum/hash/fingerprint and the
sophistication of its algorithm only affect how frequently--not
whether--the incorrect answer is generated.

> [...] The ability to forcibly create a hash collision means 
> absolutely nothing in the context of deduplication.

Of course it does.  Most examples in the literature concern storing
crafted-data-pattern-A ("pay me one dollar") in order for the data to be
read later as something different ("pay me one million dollars").  It
can't have escaped your attention that every day, some yahoo crafts
another buffer-or-stack overflow exploit; some of them are brilliant.
The notion that the bad guys will never figure out a way to plant a
silent data-change based on checksum/hash/fingerprint collisions is,
IMO, naive.

> What matters is the chance that two
> random chunks would have a hash collision. With a 128-bit and 160-bit
> key space, the odds of that happening are 1 in 2128 with MD5, and 1 in
> 2160 with SHA-1. That's 1038 and 1048, respectively. If you 

Grasshopper, the wisdom is not in the numbers, it is in remembering that
HTML will not paste into ASCII well.  But I suspect you mean "one in
2^128" or similar.

Those are impressive, and dare I guess, vendor-supplied, numbers.  And
they're meaningless.  We do not care about the odds that a particular
block "the quick brown fox jumps over the lazy dog"
checksums/hashes/fingerprints to the same value as another particular
block "now is the time for all good men to come to the aid of their
party."  Of _course_ that will be astronomically unlikely, and with
sufficient hand-waving (to quote your article:  the odds of a hash
collision with two random chunks are roughly
1,461,501,637,330,900,000,000,000,000 times greater than the number of
bytes in the known computing universe") these totally meaningless
numbers can seem important.

They're not.  What _is_ important?  To me, it's important that if I read
back any of the N terrabytes of data I might store this week, I get the
same data that was written, not a silently changed version because the
checksum/hash/fingerprint of one block that I wrote collides with
another cheksum/hash/fingerprint.  I can NOT have that happen to any
block--in a file clerk's .pst, a directory inode or the finance
database.  "Probably, it won't happen" is not acceptable.

> Let's compare those odds with the odds of an unrecoverable 
> read error on a typical disk--approximately 1 in 100 trillion

Bogus comparison.  In this straw man, that 1/100,000,000,000,000 read
error a) probably doesn't affect anything because of the higher-level
RAID array it's in and b) if it does, there's an error, a
we-could-not-read-this-data, you-can't-proceed, stop, fail,
get-it-from-another-source error--NOT a silent changing of the data from
foo to bar on every read with no indication that it isn't the data that
was written.

> If you want to talk about the odds of something bad happening and not
> knowing it, keep using tape. Everyone who has worked with tape for any
> length of time has experienced a tape drive writing something that it
> then couldn't read.

That's not news, and why 

[Veritas-bu] NB 6.5 and vxlogview

[Brooks, Jason]

I took the plunge to 6.5 last week.  All has been fine, save for one, always
contrary NDMP device.

In dealing with Symantec on the case, I've been trying to get the logs for
Originator ID 134 and 151 using the following syntax, with various
permutations:

vxlogview -o 151 -b "mm/dd/ HH:MM:SS" -e "mm/dd/ HH:MM:SS"
I've even done this:

vxlogview -o 151

Nothing.  When I look at the /usr/openv/logs directory, I clearly see files
with originator ID 151 there, and they are not empty.

Anyone else had issues with vxlogview in 6.5?  The media server where this
is happening is RHEL 3.

Thanks,
Jason


Jason Brooks
Computer Systems Engineer
IITS - Longwood University
voice - (434) 395-2034
fax - (434) 395-2035
mailto:<[EMAIL PROTECTED]> 


smime.p7s
Description: S/MIME cryptographic signature
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Netback 6.0 and 6.5 Exchange 2003 mail recovery

[Spearman, David]

James,

NBU has been able to do mailbox level backups for some time now
(includes version 6 and before). If you already have a valid exchange
client license all you have to do is set the policy up. Careful reading
of manual is suggested. 

However it would appear that the code writers for BackupExec have stolen
a march on the NBU folks. I am playing around with the BE11d exchange
backups now. With it all you need is a full backup of the exchange DB
(preferably to dssu) and whatever incrementals you may desire and the
code will open up the database backup and let you drill down. So far it
seems to be working rather well and it is sure a lot better than the
tedious and lengthy mailbox backups offered by nbu. Our sales weenine
tells us nbu will be able to do this mid 2008.

David Spearman
County of Henrico, Va.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jimlksd
Sent: Tuesday, September 25, 2007 1:30 PM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] Netback 6.0 and 6.5 Exchange 2003 mail recovery



I have heard the NBU 6.5 can recover a single email to Exchange 2003
server? [Question] 

Can NBU 6.0 do that?

+--
|This was sent by [EMAIL PROTECTED] via Backup Central. Forward 
|SPAM to [EMAIL PROTECTED]
+--


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] How to backup 30TB of data

[Martin, Jonathan]

Yes, but verify speeds before you buy.  I've got 3TB of NDMP Backups
running at 6MB/sec.  It takes FOREVER.  We're currently backing up the
data via NFS shares at 20MB/sec until Sun / StorageTek can get their NAS
NDMP implementation fixed.

-Jonathan

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Liddle,
Stuart
Sent: Wednesday, September 26, 2007 10:34 AM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] How to backup 30TB of data

One wordNDMP.  Forget about doing it in a reasonable amount of time
using CIFS.

Also, define "reasonable time"?

--stuart

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of King5899
Sent: Tuesday, September 25, 2007 2:46 PM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] How to backup 30TB of data


I have a new customer coming in that has 30 TB of SAN that they want to
put behind 2 Windows servers acting as a clustered NAS Gateway.(Not my
idea). The directory structure includes tens of millions of small images
spread across 10 of millions of directories. Currently they backup their
windows servers at a rate of about 25 GB an hour, however the data could
pass over the fiber network to the fiber tape drives. I am entertaining
SAN snapshots, and backing up the snapshots from the backup server, but
not sure if that is the best solution.

How would I possibly back this up in a reasonable time?

Any help would be appreciated.

MJK

+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] How to backup 30TB of data

[Hall, Christian N.]

MJK, 

How large are you backups?  The number of files in one backup? 7MB/sec,
that's what I am seeing here on my hosts. Also, what type of external
storage and OS? I have tried a number of strategies for backing up my
data including the following with little performance increases.  All of
my backups are SAN based going through a EMC 9513, Emulex 9802-E HBA
with symmterix attached storage running netbackup 5.1MP6, T9904B tape
drives, and SSO 

1.  Flash backups 
2.  Synthetic backups
3.  multi-plexing | multi-streaming
4.  Wild cards in backup selections
5.  calendar based backups 


As of now, I am trying to get the storage folks to re-design there disk
presentation by consolidating into NAS and trying to do NDMP based
backups versus the hosts doing the data push to tape. Evidently because
my data is very similar to yours with over 40 million files one host it
seems that the bottle neck is the windows host even when I try different
strategies of backing up...

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of King5899
Sent: Tuesday, September 25, 2007 5:46 PM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] How to backup 30TB of data


I have a new customer coming in that has 30 TB of SAN that they want to
put behind 2 Windows servers acting as a clustered NAS Gateway.(Not my
idea). The directory structure includes tens of millions of small images
spread across 10 of millions of directories. Currently they backup their
windows servers at a rate of about 25 GB an hour, however the data could
pass over the fiber network to the fiber tape drives. I am entertaining
SAN snapshots, and backing up the snapshots from the backup server, but
not sure if that is the best solution.

How would I possibly back this up in a reasonable time? 

Any help would be appreciated.

MJK

+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] How to backup 30TB of data

[Liddle, Stuart]

One wordNDMP.  Forget about doing it in a reasonable amount of time using 
CIFS.

Also, define "reasonable time"?

--stuart

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of King5899
Sent: Tuesday, September 25, 2007 2:46 PM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] How to backup 30TB of data


I have a new customer coming in that has 30 TB of SAN that they want to put 
behind 2 Windows servers acting as a clustered NAS Gateway.(Not my idea). The 
directory structure includes tens of millions of small images spread across 10 
of millions of directories. Currently they backup their windows servers at a 
rate of about 25 GB an hour, however the data could pass over the fiber network 
to the fiber tape drives. I am entertaining SAN snapshots, and backing up the 
snapshots from the backup server, but not sure if that is the best solution.

How would I possibly back this up in a reasonable time?

Any help would be appreciated.

MJK

+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] How to backup 30TB of data

[Justin Piszcz]

On Tue, 25 Sep 2007, King5899 wrote:

>
> I have a new customer coming in that has 30 TB of SAN that they want to put 
> behind 2 Windows servers acting as a clustered NAS Gateway.(Not my idea). The 
> directory structure includes tens of millions of small images spread across 
> 10 of millions of directories. Currently they backup their windows servers at 
> a rate of about 25 GB an hour, however the data could pass over the fiber 
> network to the fiber tape drives. I am entertaining SAN snapshots, and 
> backing up the snapshots from the backup server, but not sure if that is the 
> best solution.
>
> How would I possibly back this up in a reasonable time?
Your best solution, look at Flash Backup if there are millions of files.
With 30TiB of data, that may present a problem of it in itself, do you 
have a fiber channel mesh that your tape drives have access to?

>
> Any help would be appreciated.
>
> MJK
>
> +--
> |This was sent by [EMAIL PROTECTED] via Backup Central.
> |Forward SPAM to [EMAIL PROTECTED]
> +--
>
>
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 6.5 or 6.0MP5

[Justin Piszcz]

Does anyone using 6.5 use catalog compression and how does it work for 
them?  I am asking because of the catalog compression bug in 6.0MP5.

Justin.

On Wed, 26 Sep 2007, Preston, Douglas L wrote:

> I didn't have any gotcha's.  I am running 6.5 in production on my master
> server and 5 san media servers and a media server.  I have about 50 of
> my 250 clients upgraded to 6.5. The rest of the clients are 5.1 MP4
> through 6.0 MP5.
>
>
> Doug Preston
> Systems Engineer
> Land America Tax and Flood Services
> Phone 626-339-5221 Ext 1104
> Email  [EMAIL PROTECTED]
>
>
> 
> 
> NOTICE: This electronic mail transmission may constitute a communication
> that is legally privileged. It is not intended for transmission to, or
> receipt by, any unauthorized persons. If you have received this
> electronic mail transmission in error, please delete it from your system
> without copying it, and notify the sender by reply e-mail, so that our
> address record can be corrected.
> 
> 
>
>
>
>
> -Original Message-
> From: Cruice, Daniel (US - Glen Mills) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 26, 2007 5:15 AM
> To: Preston, Douglas L; Mike Kiles; veritas-bu@mailman.eng.auburn.edu
> Subject: RE: [Veritas-bu] NBU 6.5 or 6.0MP5
>
> Any "gotcha" when you did the upgrade?  Are you running it in
> production? Or Dev / QA?
>
> Thanks
> Dan
>
> -Original Message-
> From: Preston, Douglas L [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 25, 2007 4:58 PM
> To: Mike Kiles; veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] NBU 6.5 or 6.0MP5
>
> As far as I am concerned 6.5 is better.  I have had far less issues with
> it that I did with any 6.0 MP#.  If you have any reporting software it
> will break it.  The licensing has changed in 6.5 it now includes BMR and
> a few other changes in whats included or not included.
>
> If you are going to upgrade I wouold go 6.5 instead of having to do it
> twice.  Make sure your support contract is up to date when you do the
> upgrade to either one for thoe unforseen gotcha's that can occur.
>
>
> Doug Preston
> Systems Engineer
> Land America Tax and Flood Services
> Phone 626-339-5221 Ext 1104
> Email  [EMAIL PROTECTED]
>
>
> 
> 
> NOTICE: This electronic mail transmission may constitute a communication
> that is legally privileged. It is not intended for transmission to, or
> receipt by, any unauthorized persons. If you have received this
> electronic mail transmission in error, please delete it from your system
> without copying it, and notify the sender by reply e-mail, so that our
> address record can be corrected.
> 
> 
>
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mike
> Kiles
> Sent: Tuesday, September 25, 2007 12:54 PM
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: [Veritas-bu] NBU 6.5 or 6.0MP5
>
> I am running NBU 6.0 MP4 on Windows, lookig to upgrade to 6.0MP5 or 6.5
> I was wondering if any of you have any insights on which is better
> and/or less painful way to go?
> Thx
>
>
>
> 
> 
> Be a better Heartthrob. Get better relationship answers from someone who
> knows. Yahoo! Answers - Check it out.
> http://answers.yahoo.com/dir/?link=list&sid=396545433
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
> This message (including any attachments) contains confidential
> information intended for a specific individual and purpose, and is
> protected by law. If you are not the intended recipient, you should
> delete this message and are hereby notified that any disclosure,
> copying, or distribution of this message, or the taking of any action
> based on it, is strictly prohibited.
>
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 6.5 or 6.0MP5

[Preston, Douglas L]

I didn't have any gotcha's.  I am running 6.5 in production on my master
server and 5 san media servers and a media server.  I have about 50 of
my 250 clients upgraded to 6.5. The rest of the clients are 5.1 MP4
through 6.0 MP5.


Doug Preston
Systems Engineer
Land America Tax and Flood Services
Phone 626-339-5221 Ext 1104
Email  [EMAIL PROTECTED]




NOTICE: This electronic mail transmission may constitute a communication
that is legally privileged. It is not intended for transmission to, or
receipt by, any unauthorized persons. If you have received this
electronic mail transmission in error, please delete it from your system
without copying it, and notify the sender by reply e-mail, so that our
address record can be corrected.






-Original Message-
From: Cruice, Daniel (US - Glen Mills) [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 26, 2007 5:15 AM
To: Preston, Douglas L; Mike Kiles; veritas-bu@mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] NBU 6.5 or 6.0MP5

Any "gotcha" when you did the upgrade?  Are you running it in
production? Or Dev / QA?

Thanks
Dan

-Original Message-
From: Preston, Douglas L [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 25, 2007 4:58 PM
To: Mike Kiles; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] NBU 6.5 or 6.0MP5

As far as I am concerned 6.5 is better.  I have had far less issues with
it that I did with any 6.0 MP#.  If you have any reporting software it
will break it.  The licensing has changed in 6.5 it now includes BMR and
a few other changes in whats included or not included.  

If you are going to upgrade I wouold go 6.5 instead of having to do it
twice.  Make sure your support contract is up to date when you do the
upgrade to either one for thoe unforseen gotcha's that can occur.


Doug Preston
Systems Engineer
Land America Tax and Flood Services
Phone 626-339-5221 Ext 1104
Email  [EMAIL PROTECTED]




NOTICE: This electronic mail transmission may constitute a communication
that is legally privileged. It is not intended for transmission to, or
receipt by, any unauthorized persons. If you have received this
electronic mail transmission in error, please delete it from your system
without copying it, and notify the sender by reply e-mail, so that our
address record can be corrected.






-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike
Kiles
Sent: Tuesday, September 25, 2007 12:54 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] NBU 6.5 or 6.0MP5

I am running NBU 6.0 MP4 on Windows, lookig to upgrade to 6.0MP5 or 6.5
I was wondering if any of you have any insights on which is better
and/or less painful way to go? 
Thx


   


Be a better Heartthrob. Get better relationship answers from someone who
knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu 
 
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and is
protected by law. If you are not the intended recipient, you should
delete this message and are hereby notified that any disclosure,
copying, or distribution of this message, or the taking of any action
based on it, is strictly prohibited.

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] Backing up Vista on 5.1?

[John Yu]

Hi Folks,

Has anyone had any luck backing up Windows Vista with Netbackup 5.1?
(I know Vista is only official supported in 6.x).

We are trying to back up a Vista box on a Solaris NB5.1MP6 media server.

We are seeing that Netbackup is incorrectly following Vista junction
points (similar to "hard-links" in unix) even though "Cross mount points
is not selected".  This causes duplicate data to be backed up.  In Vista,
there are user profiles junctions that loop back to itself.  When
Netbackup encounters these, it attempts to traverse the junction until
it reaches the 1024byte filename limit (watch out if you have to restore
this!). This results in many status "1" errors.

About Vista junction points:

  http://www.svrops.com/svrops/articles/jpoints.htm
  http://msdn2.microsoft.com/en-us/library/Aa819663.aspx

According to Microsoft, a special API must be used in order to properly
traverse a filesystem otherwise.  Supposedly this is built into Vista's
VSS service (really only supported for Windows 2003 server on Netbackup 
5.x).

As a work around, we tried backing up a Vista box by selecting VSS for
the open file option but it appears that Netbackup is still traversing the
Vista junction points.

Has anyone else had any luck with backing up Vista?

Thanks,
John Yu
Boston University, OIT Operations


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Backing up Vista on 5.1?

[WEAVER, Simon (external)]

Not heard any announcement for 5.1, only 6.5

You may have seen this already, but just in case.

http://ftp.support.veritas.com/pub/support/products/NetBackup_Enterprise_Ser
ver/278064.pdf

Regards

Simon Weaver
3rd Line Technical Support
Windows Domain Administrator 

EADS Astrium Limited, B23AA IM (DCS)
Anchorage Road, Portsmouth, PO3 5PU

Email: [EMAIL PROTECTED]



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Yu
Sent: Wednesday, September 26, 2007 3:11 PM
To: veritas-bu@mailman.eng.auburn.edu
Cc: John Yu
Subject: [Veritas-bu] Backing up Vista on 5.1?



Hi Folks,

Has anyone had any luck backing up Windows Vista with Netbackup 5.1? (I know
Vista is only official supported in 6.x).

We are trying to back up a Vista box on a Solaris NB5.1MP6 media server.

We are seeing that Netbackup is incorrectly following Vista junction points
(similar to "hard-links" in unix) even though "Cross mount points is not
selected".  This causes duplicate data to be backed up.  In Vista, there are
user profiles junctions that loop back to itself.  When Netbackup encounters
these, it attempts to traverse the junction until it reaches the 1024byte
filename limit (watch out if you have to restore this!). This results in
many status "1" errors.

About Vista junction points:

  http://www.svrops.com/svrops/articles/jpoints.htm
  http://msdn2.microsoft.com/en-us/library/Aa819663.aspx

According to Microsoft, a special API must be used in order to properly
traverse a filesystem otherwise.  Supposedly this is built into Vista's VSS
service (really only supported for Windows 2003 server on Netbackup 
5.x).

As a work around, we tried backing up a Vista box by selecting VSS for the
open file option but it appears that Netbackup is still traversing the Vista
junction points.

Has anyone else had any luck with backing up Vista?

Thanks,
John Yu
Boston University, OIT Operations


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

This email (including any attachments) may contain confidential and/or 
privileged information or information otherwise protected from disclosure. If 
you are not the intended recipient, please notify the sender immediately, do 
not copy this message or any attachments and do not use it for any purpose or 
disclose its content to any person, but delete this message and any attachments 
from your system. Astrium disclaims any and all liability if this email 
transmission was virus corrupted, altered or falsified.
-
Astrium Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] How to backup 30TB of data

[King5899]

I have a new customer coming in that has 30 TB of SAN that they want to put 
behind 2 Windows servers acting as a clustered NAS Gateway.(Not my idea). The 
directory structure includes tens of millions of small images spread across 10 
of millions of directories. Currently they backup their windows servers at a 
rate of about 25 GB an hour, however the data could pass over the fiber network 
to the fiber tape drives. I am entertaining SAN snapshots, and backing up the 
snapshots from the backup server, but not sure if that is the best solution.

How would I possibly back this up in a reasonable time? 

Any help would be appreciated.

MJK

+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] Netback 6.0 and 6.5 Exchange 2003 mail recovery

[jimlksd]

I have heard the NBU 6.5 can recover a single email to Exchange 2003 server? 
[Question] 

Can NBU 6.0 do that?

+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 6.5 or 6.0MP5

[Preston, Douglas L]

The activity files changed from flat files to a .db file so the
reporting software can not grab the data. At least it broke Bocada.

Doug Preston
Systems Engineer
Land America Tax and Flood Services
Phone 626-339-5221 Ext 1104
Email  [EMAIL PROTECTED]




NOTICE: This electronic mail transmission may constitute a communication
that is legally privileged. It is not intended for transmission to, or
receipt by, any unauthorized persons. If you have received this
electronic mail transmission in error, please delete it from your system
without copying it, and notify the sender by reply e-mail, so that our
address record can be corrected.






-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of A Darren
Dunham
Sent: Tuesday, September 25, 2007 3:37 PM
To: Veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] NBU 6.5 or 6.0MP5

On Tue, Sep 25, 2007 at 04:58:02PM -0400, Preston, Douglas L wrote:
> As far as I am concerned 6.5 is better.  I have had far less issues 
> with it that I did with any 6.0 MP#.  If you have any reporting 
> software it will break it.

Do you know the mechanism of this breakage?  Do some of the tools change
output or something?

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://www.taos.com/
Got some Dr Pepper?   San Francisco, CA bay area
 < This line left intentionally blank to confuse you. >
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Tapeless backup environments?

[Jeff Lightner]

Most of this while well documented seems to boil down to the same
alarmist notion that had people trying to ban cell phones in gas
stations.  The possibility that something untoward COULD happen does NOT
mean it WILL happen.  To date I don't know of a single gas pump
explosion or car fire that was traced to cell phone usage at the pump.
Oddly enough though no one monitors gas pumps to be sure users aren't
re-entering their vehicles and fires HAVE been traced to static
electricity caused by that.

If odds are so important it seems it would be important to worry about
the odds that your data center, your offsite storage location and your
Disaster Recovery site will all be taken out at the same time.

I also suggest the argument is flawed because it seems to imply that
only the cksum is stored and no actual the data - it is original
compressed data AND the cksum that result in the restore - not the cksum
alone.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of bob944
Sent: Wednesday, September 26, 2007 4:03 AM
To: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Tapeless backup environments?

cpreston:
> >Simplistically, it checksums the "block" and looks in a table of
> >checksums-of-"blocks"-that-it-already-stores to see if the identical
> > data already lives there.  
> 
> To what hole do you refer? 

The idea that N bits of data can unambiguously be represented by fewer
than N bits.  Anyone who claims to the contrary might as well knock out
perpetual motion, antigravity and faster-than-light travel while they're
on a roll.

> I see one in your simplistic example, but
> not in what actually happens (which require a much longer technical
> explanation).

Hence my introduction that began with "[s]implistically."  But throw in
all the "much longer technical explanation" you like, any process which
compares a reduction-of-data to another reduction-of-data will sooner or
later return "foo" when what was originally stored was "bar."


cpreston:
> There are no products in the market that rely solely on a checksum to
> identify redundant data.  There are a few that rely solely on 
> a 160-bit
> hash, which is significantly larger than a checksum (typically 12-16

No importa.  The length of the checksum/hash/fingerprint and the
sophistication of its algorithm only affect how frequently--not
whether--the incorrect answer is generated.

> [...] The ability to forcibly create a hash collision means 
> absolutely nothing in the context of deduplication.

Of course it does.  Most examples in the literature concern storing
crafted-data-pattern-A ("pay me one dollar") in order for the data to be
read later as something different ("pay me one million dollars").  It
can't have escaped your attention that every day, some yahoo crafts
another buffer-or-stack overflow exploit; some of them are brilliant.
The notion that the bad guys will never figure out a way to plant a
silent data-change based on checksum/hash/fingerprint collisions is,
IMO, naive.

> What matters is the chance that two
> random chunks would have a hash collision. With a 128-bit and 160-bit
> key space, the odds of that happening are 1 in 2128 with MD5, and 1 in
> 2160 with SHA-1. That's 1038 and 1048, respectively. If you 

Grasshopper, the wisdom is not in the numbers, it is in remembering that
HTML will not paste into ASCII well.  But I suspect you mean "one in
2^128" or similar.

Those are impressive, and dare I guess, vendor-supplied, numbers.  And
they're meaningless.  We do not care about the odds that a particular
block "the quick brown fox jumps over the lazy dog"
checksums/hashes/fingerprints to the same value as another particular
block "now is the time for all good men to come to the aid of their
party."  Of _course_ that will be astronomically unlikely, and with
sufficient hand-waving (to quote your article:  the odds of a hash
collision with two random chunks are roughly
1,461,501,637,330,900,000,000,000,000 times greater than the number of
bytes in the known computing universe") these totally meaningless
numbers can seem important.

They're not.  What _is_ important?  To me, it's important that if I read
back any of the N terrabytes of data I might store this week, I get the
same data that was written, not a silently changed version because the
checksum/hash/fingerprint of one block that I wrote collides with
another cheksum/hash/fingerprint.  I can NOT have that happen to any
block--in a file clerk's .pst, a directory inode or the finance
database.  "Probably, it won't happen" is not acceptable.

> Let's compare those odds with the odds of an unrecoverable 
> read error on a typical disk--approximately 1 in 100 trillion

Bogus comparison.  In this straw man, that 1/100,000,000,000,000 read
error a) probably doesn't affect anything because of the higher-level
RAID array it's in and b) if it does, there's an error, a
we-could-not-read-this-data, you-can't-proceed, stop, fail,
get-it-from-anoth

Re: [Veritas-bu] NBU 6.5 or 6.0MP5 - Results

[Mike Kiles]

Thanks to all who replied.

I have recieved 7 replies so far,  6 in favor of 6.5
and one was neutral.

MK
--- Mike Kiles <[EMAIL PROTECTED]> wrote:

> I am running NBU 6.0 MP4 on Windows, lookig to
> upgrade
> to 6.0MP5 or 6.5
> I was wondering if any of you have any insights on
> which is better and/or less painful way to go? 
> Thx
> 
> 
>
>

> Be a better Heartthrob. Get better relationship
> answers from someone who knows. Yahoo! Answers -
> Check it out. 
>
http://answers.yahoo.com/dir/?link=list&sid=396545433
> ___
> Veritas-bu maillist  - 
> Veritas-bu@mailman.eng.auburn.edu
>
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 



  

Luggage? GPS? Comic books? 
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Backing up a SAN

[Karl . Rossing]

[EMAIL PROTECTED] wrote on 09/25/2007 07:28:28 PM:

> With NetBackup 6.5, you have the option of a ?SAN client? which is 
> essentially a media server client but without tape drivers.   This 
> allows you to access your SAN-based data and write to a SAN-based 
> disk storage unit.  No network traffic is involved except for the 
> catalog data.

Wow that looks neat, so i did a bit of research. I couldn't find much on 
the symantec site but i did find this:
http://www.dns.at/dnsat/unternehmen/promotions/447a6170c5fabb4a9bf068f6143dd41d.0.0/Veritas_NetBackup_6_5_Clients___Agents_-_Factsheet.pdf
"SAN Client?The SAN client offloads backup traffic from
the LAN and allows for fast backups over the SAN at
approximately 150MB/sec. The SAN client can send data
to a variety of our new disk options and allows you to
back up and restore to disk over the SAN. Data is sent to
media servers via SCSI commands over the SAN rather
than TCP/IP over the LAN to optimize performance. SAN
Clients are supported on all major platforms."

So the SAN client seems to be part of the Enterprise Client.

My question is, can the Enterprise(SAN) client be used with a Database 
client. I'd imagine that it can.

Karl

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Firewall configuration setup

[Paul Keating]

Not under the firewall tab...it's under the Master's "Client Attributes" tab.
"No connect back" is what tells your 5.x client to only talk to the server via 
the VNETD port.
ie. checking "no connect back" is how you "enable" VNETD

The client doesn't need bpcd outbound.

You need bpcd from master/media -> client
And VNETD from client -> master/media

Paul

-- 


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of rcarlisle
> Sent: September 25, 2007 9:07 PM
> To: 'David Rock'; veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Firewall configuration setup
> 
> 
> No connect back for each client under the firewall 
> configuration tab?  With
> 6.0, you were only supposed to have to use VNETD... Is there 
> any way to
> force the 5.0 client to only use vnetd and not open up the bpcd port? 
> 
> 
>  
>  
> Reneé Carlisle 
> ServerWare Corporation
> 
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of David Rock
> Sent: Tuesday, September 25, 2007 8:28 PM
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Firewall configuration setup
> 
> * rcarlisle <[EMAIL PROTECTED]> [2007-09-25 19:39]:
> >  
> > Can someone please help me with the following configuration:
> > 
> > Client - NBU 5.1
> > Master/Media - NBU 6.5
> > 
> > Port 13724 VNETD is opened both ways. What needs to be set 
> up in NBU on
> > Master server and Client...global attributes, firewall 
> settings...reserved
> > portsI still can't get the master server to see the 
> client in hosts
> > attributes.
> 
> There's pretty extensive documentation in the manuals for this (more
> than most people should _ever_ read), but the minimum you need is the
> following:
> 
> Server -> Client 13782(bpcd)
> Client -> Server 13724(vnetd)
> Client -> Server 13720(bprd) - but only if you need client initiated
> stuff.
> 
> In order for vnetd to work properly, you need to add the no 
> connectback
> option in the client properties on the master server only.  
> You can get
> to the client settings using bpclient, too.
> 
> vnetd Server -> Client is pretty useless.
> 
> There are some other things you _could_ open up, but that 
> should get you
> where you need to be.
> 
> -- 
> David Rock
> [EMAIL PROTECTED]
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 
> 
> 
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 


La version française suit le texte anglais.



This email may contain privileged and/or confidential information, and the Bank 
of
Canada does not waive any related rights. Any distribution, use, or copying of 
this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately 
from
your system and notify the sender promptly by email that you have done so. 



Le présent courriel peut contenir de l'information privilégiée ou 
confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute 
diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires désignés est interdite. Si vous 
recevez
ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans 
délai à
l'expéditeur un message électronique pour l'aviser que vous avez éliminé de 
votre
ordinateur toute copie du courriel reçu.

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 6.0 MP4 - BMR Physical to Virtual Restore

[Brooks, Jason]

I recently attended the Symantec BMR class and we did just that to a VMWare
virtual server.  I didn't go through the VMWare setup, but below is what was
used.

The mass storage drivers we used were LSI Logic SCSI drivers that would be
supported in the VM.  At least in the VMWare world, you could specify which
type of disk to use in setup: SCSI or IDE.

What type are you using?  If they're not in the PE, you may be able to get
NBU support to add them to a custom PE image.  Not sure, but I heard of that
in the class.

Jason


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of O'Byrne, Colette
> Sent: Wednesday, September 26, 2007 5:12 AM
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: [Veritas-bu] NBU 6.0 MP4 - BMR Physical to Virtual Restore
> 
> Good morning, 
>  
> Does anyone have any experience using BMR Fast Boot CD to 
> recover a physical machine to a virtual machine; I am 
> currently testing this and have some questions relating to 
> the "prepare to restore" configuration and the mass storage 
> drivers to be used during the restore when it comes to 
> virtual machines?  Thanks in advance. Colette
>  
>  
> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 6.5 or 6.0MP5

[Dyck, Jonathan]

Any report on this for Aptare anyone?

Thanks,
Jon


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Cruice,
Daniel (US - Glen Mills)
Sent: Wednesday, September 26, 2007 8:21 AM
To: A Darren Dunham; Veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] NBU 6.5 or 6.0MP5

As far as the reporting tools, NBU 6.5 will break Bocada.  Not sure why,
but we had Bocada in here last week discussing our options, and they
simply said "Bocada will break".  And they would not give us a ETA as to
when they will have NBU 6.5 support for Bocada.  But they did say they
are working on it.

Thanks
Dan

-Original Message-
From: A Darren Dunham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 25, 2007 6:37 PM
To: Veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] NBU 6.5 or 6.0MP5

On Tue, Sep 25, 2007 at 04:58:02PM -0400, Preston, Douglas L wrote:
> As far as I am concerned 6.5 is better.  I have had far less issues
with
> it that I did with any 6.0 MP#.  If you have any reporting software it

> will break it.

Do you know the mechanism of this breakage?  Do some of the tools change
output or something?

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://www.taos.com/
Got some Dr Pepper?   San Francisco, CA bay area
 < This line left intentionally blank to confuse you. >
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu 
 
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and is
protected by law. If you are not the intended recipient, you should
delete this message and are hereby notified that any disclosure,
copying, or distribution of this message, or the taking of any action
based on it, is strictly prohibited.

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
 
 This message may contain privileged and/or confidential information.  If 
you have received this e-mail in error or are not the intended recipient, you 
may not use, copy, disseminate or distribute it; do not open any attachments, 
delete it immediately from your system and notify the sender promptly by e-mail 
that you have done so.  Thank you.

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 6.5 or 6.0MP5

[Cruice, Daniel (US - Glen Mills)]

As far as the reporting tools, NBU 6.5 will break Bocada.  Not sure why,
but we had Bocada in here last week discussing our options, and they
simply said "Bocada will break".  And they would not give us a ETA as to
when they will have NBU 6.5 support for Bocada.  But they did say they
are working on it.

Thanks
Dan

-Original Message-
From: A Darren Dunham [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 25, 2007 6:37 PM
To: Veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] NBU 6.5 or 6.0MP5

On Tue, Sep 25, 2007 at 04:58:02PM -0400, Preston, Douglas L wrote:
> As far as I am concerned 6.5 is better.  I have had far less issues
with
> it that I did with any 6.0 MP#.  If you have any reporting software it
> will break it.

Do you know the mechanism of this breakage?  Do some of the tools change
output or something?

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://www.taos.com/
Got some Dr Pepper?   San Francisco, CA bay area
 < This line left intentionally blank to confuse you. >
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu 
 
This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and is protected by law. If you 
are not the intended recipient, you should delete this message and are hereby 
notified that any disclosure, copying, or distribution of this message, or the 
taking of any action based on it, is strictly prohibited.

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 6.5 or 6.0MP5

[Cruice, Daniel \(US - Glen Mills\)]

Any "gotcha" when you did the upgrade?  Are you running it in
production? Or Dev / QA?

Thanks
Dan

-Original Message-
From: Preston, Douglas L [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 25, 2007 4:58 PM
To: Mike Kiles; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] NBU 6.5 or 6.0MP5

As far as I am concerned 6.5 is better.  I have had far less issues with
it that I did with any 6.0 MP#.  If you have any reporting software it
will break it.  The licensing has changed in 6.5 it now includes BMR and
a few other changes in whats included or not included.  

If you are going to upgrade I wouold go 6.5 instead of having to do it
twice.  Make sure your support contract is up to date when you do the
upgrade to either one for thoe unforseen gotcha's that can occur.


Doug Preston
Systems Engineer
Land America Tax and Flood Services
Phone 626-339-5221 Ext 1104
Email  [EMAIL PROTECTED]




NOTICE: This electronic mail transmission may constitute a communication
that is legally privileged. It is not intended for transmission to, or
receipt by, any unauthorized persons. If you have received this
electronic mail transmission in error, please delete it from your system
without copying it, and notify the sender by reply e-mail, so that our
address record can be corrected.






-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike
Kiles
Sent: Tuesday, September 25, 2007 12:54 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] NBU 6.5 or 6.0MP5

I am running NBU 6.0 MP4 on Windows, lookig to upgrade to 6.0MP5 or 6.5
I was wondering if any of you have any insights on which is better
and/or less painful way to go? 
Thx


   


Be a better Heartthrob. Get better relationship answers from someone who
knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu 
 
This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and is protected by law. If you 
are not the intended recipient, you should delete this message and are hereby 
notified that any disclosure, copying, or distribution of this message, or the 
taking of any action based on it, is strictly prohibited.

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] De-Dupe with NBU PureDisk

[Cruice, Daniel \(US - Glen Mills\)]

Something else worth looking at is datadomain...we just had a rep come
is a review it with us, we are looking to try to get a demo box in here.
Might be a little cheaper the PureDisk especially, since Symantec has
changed the priceing of their product.  I believe they are moving to a
per data size pricing. 

Thanks
Dan
-Original Message-
From: Ambrose, Monte [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 25, 2007 2:00 PM
To: Curtis Preston; Robin Small; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] De-Dupe with NBU PureDisk

We are using PureDisk for our remote sites and it is doing a great job
with the de-dupe.  We are backing up across networks with very high
latency and at T1 or even less speeds

-- Monte

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Curtis
Preston
Sent: Monday, September 24, 2007 8:52 PM
To: Robin Small; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] De-Dupe with NBU PureDisk

That scenario is exactly what Puredisk was designed for.  If it's
typical user data (i.e. not auto-generated data like seismic or medical
imaging), I'd estimate less than 1% a day going across the wire, often
less than 0.5%.  (Your mileage may vary, of course.)

---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robin
Small
Sent: Monday, September 24, 2007 7:55 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] De-Dupe with NBU PureDisk

The talk about the tapeless environments has got me thinking, and oddly
enough, we just got a visit from our Quantum sales reps talking about
the DXi series dedupe products.

Any of you folks have much experience with the Symantec NBU PureDisk
approach?

We have some remote offices that I currently have media servers at with
small slot-count autoloaders. I *hate* having to go change tapes
(they're all in-town but still a pita). I'm curious about the
utilization and replication over relatively slow T1 links.

~ Robin


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu 
 
This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and is protected by law. If you 
are not the intended recipient, you should delete this message and are hereby 
notified that any disclosure, copying, or distribution of this message, or the 
taking of any action based on it, is strictly prohibited.

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Tapeless backup environments?

[Chris Freemantle]

Just a teensy point - LTO3 tapes should store 400Gb natively. They're 
marketed as having a capacity up to 800Gb, but that's with 2:1 
compression. We normally get about 550GB for MRI data.

LTO4 are available with 800Gb native capacity. The drives can also 
encrypt data.

Dave Markham wrote:
> Guys i've just read this thread and can say im very interested in it.
> The first thing is i learned a new term called deduplication which i
> didn't know existed.
> 
> Question : I gather Deduplication is using other software. DataDomain i
> think i saw mentioned. Where does this fit in with Netbackup and does
> the software reside on every client or just a server somewhere?
> 
> Ok, so im trying to kit refresh a backup environment for a customer
> which has 2 sites. Production and DR about 200 miles apart. There is a
> link between the sites but the customer will probably frown on increased
> bandwidth charges to transfer backup data across for DisasterRecovery
> purposes.
> 
> Data is probably only 1 TB for the site with perhaps 70% being required
> to be transfered daily to offsite media.
> 
> Currently i use tape and i was just speccing a new tape system as i
> thought by using disk based backups, and retentions of weekly/monthly
> backups lasting say 6 weeks, im going to need a LOT of disk, plus the
> bandwidth transfer costs to DR site
> 
> LTO3 tapes are storing 200gb a tape which is pretty good compared to
> disk i thought.
> 
> I guess in my set up its a trade off between :-
> 
> Initial cost of disk array vs initial cost of tape library, drives and media
> 
> Time take to backup ( network will be bottle neck here. Still on 100Meg
> lan with just 2 DB servers using GigaBit lan to backup server.
> 
> Offsite transfer of tapes daily to offsite location vs Cost of increased
> bandwith between sites to transfer backup data.
> 
> 
> Im now confused what to propose :)
> 
> 
> 
> 

-- 
Do you want a picture of your brain - volunteer for a brain scan!
http://www.fil.ion.ucl.ac.uk/Volunteers/

Computer systems go wrong - even backup systems
Be paranoid!

Chris Freemantle, Data Manager
Wellcome Trust Centre for Neuroimaging
+44 (0)207 833 7496
www.fil.ion.ucl.ac.uk
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] LTO3 mixed LTO2 drive using LTO2 cartridges with ACSLS

[Martin Ruslan]

Dear friends,

I'm using the Storagetek Library, using ACSLS, where the drive is LTO2 and
we adding the new LTO3 drives, but we still don't have the LTO3 cartridges.
So, we still use the LTO2 cartridge for using on this LTO2 and 3 drives.
on the DR, we'll use only LTO3 drives (only for restore purposes)
So this LTO2 cartridges will always be use on LTO3 drives.

The problem is, when I want to use the LTO2 cartridges on LTO3 drives, so I
have to change the density of the LTO2 tapes right?
So I run this: vmchange -new_mt hcart3 -m dc0273.
Ok, the backup running well, the LTO2 cartridge can be used on LTO3 drives.

But, when we want to add, or eject the cartridges from the Library, and we
run the inventory robot on NBU, disaster happen.
I got this error when doing the inventory on NBU side:
Generating list of recommended changes ...Update failed: media ID DC0273 in
database has media type 'HCART3', whichdiffers from media ID DC0273 in the
robot which is (according to themedia type returned from the robot, adjusted
by media type mappings)projected to have a media type of 'HCART2'.

I think, this error comes because the ACSLS comparing his catalog database
with the NBU catalog.
Because, when I'm using other environment (without using the ACSLS), there's
no problem at all.
Is there any suggestion for this? Waiting for your help guys...

Regards,
Martin.
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] NBU 6.0 MP4 - BMR Physical to Virtual Restore

[O'Byrne, Colette]

Good morning, 
 
Does anyone have any experience using BMR Fast Boot CD to recover a
physical machine to a virtual machine; I am currently testing this and
have some questions relating to the "prepare to restore" configuration
and the mass storage drivers to be used during the restore when it comes
to virtual machines?  Thanks in advance. Colette
 
 

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Tapeless backup environments?

[bob944]

cpreston:
> >Simplistically, it checksums the "block" and looks in a table of
> >checksums-of-"blocks"-that-it-already-stores to see if the identical
> > data already lives there.  
> 
> To what hole do you refer? 

The idea that N bits of data can unambiguously be represented by fewer
than N bits.  Anyone who claims to the contrary might as well knock out
perpetual motion, antigravity and faster-than-light travel while they're
on a roll.

> I see one in your simplistic example, but
> not in what actually happens (which require a much longer technical
> explanation).

Hence my introduction that began with "[s]implistically."  But throw in
all the "much longer technical explanation" you like, any process which
compares a reduction-of-data to another reduction-of-data will sooner or
later return "foo" when what was originally stored was "bar."


cpreston:
> There are no products in the market that rely solely on a checksum to
> identify redundant data.  There are a few that rely solely on 
> a 160-bit
> hash, which is significantly larger than a checksum (typically 12-16

No importa.  The length of the checksum/hash/fingerprint and the
sophistication of its algorithm only affect how frequently--not
whether--the incorrect answer is generated.

> [...] The ability to forcibly create a hash collision means 
> absolutely nothing in the context of deduplication.

Of course it does.  Most examples in the literature concern storing
crafted-data-pattern-A ("pay me one dollar") in order for the data to be
read later as something different ("pay me one million dollars").  It
can't have escaped your attention that every day, some yahoo crafts
another buffer-or-stack overflow exploit; some of them are brilliant.
The notion that the bad guys will never figure out a way to plant a
silent data-change based on checksum/hash/fingerprint collisions is,
IMO, naive.

> What matters is the chance that two
> random chunks would have a hash collision. With a 128-bit and 160-bit
> key space, the odds of that happening are 1 in 2128 with MD5, and 1 in
> 2160 with SHA-1. That's 1038 and 1048, respectively. If you 

Grasshopper, the wisdom is not in the numbers, it is in remembering that
HTML will not paste into ASCII well.  But I suspect you mean "one in
2^128" or similar.

Those are impressive, and dare I guess, vendor-supplied, numbers.  And
they're meaningless.  We do not care about the odds that a particular
block "the quick brown fox jumps over the lazy dog"
checksums/hashes/fingerprints to the same value as another particular
block "now is the time for all good men to come to the aid of their
party."  Of _course_ that will be astronomically unlikely, and with
sufficient hand-waving (to quote your article:  the odds of a hash
collision with two random chunks are roughly
1,461,501,637,330,900,000,000,000,000 times greater than the number of
bytes in the known computing universe") these totally meaningless
numbers can seem important.

They're not.  What _is_ important?  To me, it's important that if I read
back any of the N terrabytes of data I might store this week, I get the
same data that was written, not a silently changed version because the
checksum/hash/fingerprint of one block that I wrote collides with
another cheksum/hash/fingerprint.  I can NOT have that happen to any
block--in a file clerk's .pst, a directory inode or the finance
database.  "Probably, it won't happen" is not acceptable.

> Let's compare those odds with the odds of an unrecoverable 
> read error on a typical disk--approximately 1 in 100 trillion

Bogus comparison.  In this straw man, that 1/100,000,000,000,000 read
error a) probably doesn't affect anything because of the higher-level
RAID array it's in and b) if it does, there's an error, a
we-could-not-read-this-data, you-can't-proceed, stop, fail,
get-it-from-another-source error--NOT a silent changing of the data from
foo to bar on every read with no indication that it isn't the data that
was written.

> If you want to talk about the odds of something bad happening and not
> knowing it, keep using tape. Everyone who has worked with tape for any
> length of time has experienced a tape drive writing something that it
> then couldn't read.

That's not news, and why we've been making copies of data for, oh, 50
years or so.

> Compare that to successful deduplication disk
> restores. According to Avamar Technologies Inc. (recently acquired by
> EMC Corp.), none of its customers has ever had a failed restore.

Now _there's_ an unbiased source.


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu