Re: [Veritas-bu] Fragment size for LTO4 on NBU 6.x
I agree with the principle of what you say, though it is only practical if your storage units are configured in a way that allows that. It would be pretty easy and sensible for example with Oracle servers that have SAN Media Server, and hence a Storage Unit that is only used to backup the Oracle server's own data, to set a large fragment size, as the files are likely to be large. Looking at the output of bpimaglelist is a good way to do this, see http://www.encephalon.com/perl/veritas-Netbackup_bkrep.txt. However general purpose Media Servers cannot really do this, so a compromise is needed. I agree with Brian Bahnmiller that the tape accelerate/decelerate time is a major factor in performance of the backups, and the fragment size needs to be large enough to reduce the significance of this. I'm not sure I agree that modern tapes can get round the need to fast position to the file, and then slow scan the file. As I understand it NetBackup is tracking the fragment (effectively file on tape) in which a file is located, so for a restore it can use this to fast position. That I believe is the reason to keep the fragment small, though as Gideon Wheeler says it depends on the file size. I guess the ideal would be that the fragment exactly matched the file size so each file was a fragment, for this purpose only - clearly unattainable unless you have very neat data file sizes. Opinion seems to be that a size > 8GB, maybe 16 or 20 and as much as 32GB is sensible. I must admit that is much less than I was thinking, given the default for NBU 6 is 1TB! My rough calculation suggests that at ~60MB/s a 32GB fragment takes a little over 9 minutes to write, and a 16GB fragment just over 4 1/2 minutes. So in terms of seeing the fragments tick up one can take a choice. I think the larger fragment does more to reduce the accelerate/decelerate time, so I think I will try that and see how it goes. Hopefully I can find time to test this in our lab. As we are looking at D2D2T using SLPs, it is also affected by the fragment size on the disk staging storage unit (actually AdvancedDisk). Those are large, designed to make the destaging go fast. In fact I wonder if I can aim for that ideal that each disk fragment exactly fits each tape fragment, i.e. make them the same size or at least an exact multiple. On disk I care about how many fragments there are as it will affect the performance of the file system if there are millions of small fragments. Thank you all for the responses. William D L Brown veritas-bu-boun...@mailman.eng.auburn.edu wrote on 17/09/2009 06:42:46: > I agree a 2GB fragment size for an LTO3 / 4 drive is a little on the > small size, but rather than choosing the fragment size to fit the > tape technology perhaps it would be useful to select fragment size > based on the type of the data we are backing up. Large single file > data such as image, audio or exported databases etc. would benefit > from using the larger fragment sizes. Database Agent orientated > backups such as RMAN / MSSQL could use a fragment size based on > their fileset size or multiple thereof. Whilst User home accounts, > source code project directories would use the smaller settings. Of > course all this only applies to non NDMP backups. > There is an advantage of using fragment sizing in that?s it a great > way of determining tape throughput. It?s easy to calculate the speed > of a backup if you know that its taking t minutes to backup a 2 or > 20GB fragment rather than waiting t hours for a terabyte. > Psychology: Nothing is more re-assuring then seeing the fragment > markers count up in the job details panel. Its good indicator that > all is well with that client. > As to the overhead of fragment markers in the catalogue I have no idea. > Just my 2-bits worth. > > Gideon Wheeler___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu --- This e-mail was sent by GlaxoSmithKline Services Unlimited (registered in England and Wales No. 1047315), which is a member of the GlaxoSmithKline group of companies. The registered address of GlaxoSmithKline Services Unlimited is 980 Great West Road, Brentford, Middlesex TW8 9GS. --- ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Fragment size for LTO4 on NBU 6.x
I agree a 2GB fragment size for an LTO3 / 4 drive is a little on the small size, but rather than choosing the fragment size to fit the tape technology perhaps it would be useful to select fragment size based on the type of the data we are backing up. Large single file data such as image, audio or exported databases etc. would benefit from using the larger fragment sizes. Database Agent orientated backups such as RMAN / MSSQL could use a fragment size based on their fileset size or multiple thereof. Whilst User home accounts, source code project directories would use the smaller settings. Of course all this only applies to non NDMP backups. There is an advantage of using fragment sizing in that's it a great way of determining tape throughput. It's easy to calculate the speed of a backup if you know that its taking t minutes to backup a 2 or 20GB fragment rather than waiting t hours for a terabyte. Psychology: Nothing is more re-assuring then seeing the fragment markers count up in the job details panel. Its good indicator that all is well with that client. As to the overhead of fragment markers in the catalogue I have no idea. Just my 2-bits worth. Gideon Wheeler ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Fragment size for LTO4 on NBU 6.x
This is correct, but does not work at all cases stefanos -Original Message- From: veritas-bu-boun...@mailman.eng.auburn.edu [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of oersted Sent: Wednesday, September 16, 2009 5:53 PM To: VERITAS-BU@MAILMAN.ENG.AUBURN.EDU Subject: [Veritas-bu] Fragment size for LTO4 on NBU 6.x tape drive will use LOCATE BLOCK to first file to restore, then search from there. wdlb5359 wrote: > What are people using for the fragment size on LTO4 (or I guess LTO3) with > NBU 6.x? > > I ask because the default is 1TB, i.e. more or less don't fragment. > > The argument for a large fragment is that the backup doesn't have to stop > so often as it does briefly at the end of each fragment to update the > Master, and also the inter-fragment file markers waste space..though > that's hardly a consideration on such large tapes now. > > The argument for a small fragment was that the tape can position at full > speed to the file marker for the appropriate fragment for a restore, > rather than reading the tar file from the top at read speed, which for a > large tape could be a very long time. > > We used to (dating back to DLT7000) set a 2GB fragment, as back then this > was thought a good idea in case you wanted to dd the tape to disk and read > it without NetBackup. UNIX file systems did not take files > 2GB. Well I > can't say we ever tried it and it's a silly small size now. > > But what are people using - 100GB? 200GB? Does it really make a > difference... > > William D L Brown > > > --- > This e-mail was sent by GlaxoSmithKline Services Unlimited > (registered in England and Wales No. 1047315), which is a > member of the GlaxoSmithKline group of companies. The > registered address of GlaxoSmithKline Services Unlimited > is 980 Great West Road, Brentford, Middlesex TW8 9GS. > --- > > ___ > Veritas-bu maillist - Veritas-bu < at > mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu +-- |This was sent by sola...@cablespeed.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- ___ 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] Fragment size for LTO4 on NBU 6.x
On Wed, Sep 16, 2009 at 09:13:06AM -0400, Justin Piszcz wrote: > It all depends how long you want to wait to restore a file if you have > large backups that can span a tape completely. > > With 1TB fragment size, assuming there was no compression and you needed > to restore a 10k file at the end of the tape, it would need to read the > entire thing to restore the file. Since a tape can skip forward within a file (at least modern tapes can), I don't think that's a problem. I leave fragment size on all my STUs unset (to avoid screwing up NDMP duplications) and I don't have to wait to read through long fragments when doing single file restores. -- Darren ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Fragment size for LTO4 on NBU 6.x
I'm still on LTO2 and have the max fragment size set to 8GB. That's a file every few minutes if the drive is allowed to run full speed. Will probably multiply by 2 or 4 when I ever upgrade. Jim VandeVegt VandeVegt @t yahoo.com From: oersted tape drive will use LOCATE BLOCK to first file to restore, then search from there. wdlb5359 wrote: > What are people using for the fragment size on LTO4 (or I guess LTO3) with > NBU 6.x? > > I ask because the default is 1TB, i.e. more or less don't fragment. > > The argument for a large fragment is that the backup doesn't have to stop > so often as it does briefly at the end of each fragment to update the > Master, and also the inter-fragment file markers waste space..though > that's hardly a consideration on such large tapes now. > > The argument for a small fragment was that the tape can position at full > speed to the file marker for the appropriate fragment for a restore, > rather than reading the tar file from the top at read speed, which for a > large tape could be a very long time. > > We used to (dating back to DLT7000) set a 2GB fragment, as back then this > was thought a good idea in case you wanted to dd the tape to disk and read > it without NetBackup. UNIX file systems did not take files > 2GB. Well I > can't say we ever tried it and it's a silly small size now. > > But what are people using - 100GB? 200GB? Does it really make a > difference... > > William D L Brown ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Fragment size for LTO4 on NBU 6.x
And database size. Every fragment is another record in the image database. -Original Message- From: veritas-bu-boun...@mailman.eng.auburn.edu [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of WEAVER, Simon (external) Sent: Wednesday, September 16, 2009 7:38 AM To: Justin Piszcz; Dean Cc: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Fragment size for LTO4 on NBU 6.x Ideally, I try to go for FAST restores. I feel our backups are quite quick. We also use buffer settings on some Media Servers that contains large amounts of Data. I guess it is a weigh up between performance and fast restores. Simon -Original Message- From: veritas-bu-boun...@mailman.eng.auburn.edu [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Justin Piszcz Sent: Wednesday, September 16, 2009 2:13 PM To: Dean Cc: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Fragment size for LTO4 on NBU 6.x 32GB here. It all depends how long you want to wait to restore a file if you have large backups that can span a tape completely. With 1TB fragment size, assuming there was no compression and you needed to restore a 10k file at the end of the tape, it would need to read the entire thing to restore the file. If you used a smaller fragement size, it would skip to the closest fragment to the file that needed to be restored. Don't go too small though or every time it writes a file marker, it could slow down the backup. It is all about speed of backup vs. speed of restore (and the data type being backed up/restored) as well. Justin. On Wed, 16 Sep 2009, Dean wrote: > 20GB here, using IBM 3592. I've considered making the fragment size > larger, but . if it aint broke > > > On Wed, Sep 16, 2009 at 7:26 PM, wrote: > >> What are people using for the fragment size on LTO4 (or I guess LTO3) >> with NBU 6.x? >> >> I ask because the default is 1TB, i.e. more or less don't fragment. >> >> The argument for a large fragment is that the backup doesn't have to >> stop so often as it does briefly at the end of each fragment to >> update the Master, and also the inter-fragment file markers waste >> space..though that's hardly a consideration on such large tapes now. >> >> The argument for a small fragment was that the tape can position at >> full speed to the file marker for the appropriate fragment for a >> restore, rather than reading the tar file from the top at read speed, >> which for a large tape could be a very long time. >> >> We used to (dating back to DLT7000) set a 2GB fragment, as back then >> this was thought a good idea in case you wanted to dd the tape to >> disk and read it without NetBackup. UNIX file systems did not take >> files > 2GB. Well I can't say we ever tried it and it's a silly small size now. >> >> But what are people using - 100GB? 200GB? Does it really make a >> difference... >> >> William D L Brown >> >> >> --- >> This e-mail was sent by GlaxoSmithKline Services Unlimited >> (registered in England and Wales No. 1047315), which is a member of >> the GlaxoSmithKline group of companies. The registered address of >> GlaxoSmithKline Services Unlimited is 980 Great West Road, Brentford, >> Middlesex TW8 9GS. >> --- >> >> ___ >> 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 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. -o- 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 maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Fragment size for LTO4 on NBU 6.x
Ideally, I try to go for FAST restores. I feel our backups are quite quick. We also use buffer settings on some Media Servers that contains large amounts of Data. I guess it is a weigh up between performance and fast restores. Simon -Original Message- From: veritas-bu-boun...@mailman.eng.auburn.edu [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Justin Piszcz Sent: Wednesday, September 16, 2009 2:13 PM To: Dean Cc: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Fragment size for LTO4 on NBU 6.x 32GB here. It all depends how long you want to wait to restore a file if you have large backups that can span a tape completely. With 1TB fragment size, assuming there was no compression and you needed to restore a 10k file at the end of the tape, it would need to read the entire thing to restore the file. If you used a smaller fragement size, it would skip to the closest fragment to the file that needed to be restored. Don't go too small though or every time it writes a file marker, it could slow down the backup. It is all about speed of backup vs. speed of restore (and the data type being backed up/restored) as well. Justin. On Wed, 16 Sep 2009, Dean wrote: > 20GB here, using IBM 3592. I've considered making the fragment size > larger, but . if it aint broke > > > On Wed, Sep 16, 2009 at 7:26 PM, wrote: > >> What are people using for the fragment size on LTO4 (or I guess LTO3) >> with NBU 6.x? >> >> I ask because the default is 1TB, i.e. more or less don't fragment. >> >> The argument for a large fragment is that the backup doesn't have to >> stop so often as it does briefly at the end of each fragment to >> update the Master, and also the inter-fragment file markers waste >> space..though that's hardly a consideration on such large tapes now. >> >> The argument for a small fragment was that the tape can position at >> full speed to the file marker for the appropriate fragment for a >> restore, rather than reading the tar file from the top at read speed, >> which for a large tape could be a very long time. >> >> We used to (dating back to DLT7000) set a 2GB fragment, as back then >> this was thought a good idea in case you wanted to dd the tape to >> disk and read it without NetBackup. UNIX file systems did not take >> files > 2GB. Well I can't say we ever tried it and it's a silly small size now. >> >> But what are people using - 100GB? 200GB? Does it really make a >> difference... >> >> William D L Brown >> >> >> --- >> This e-mail was sent by GlaxoSmithKline Services Unlimited >> (registered in England and Wales No. 1047315), which is a member of >> the GlaxoSmithKline group of companies. The registered address of >> GlaxoSmithKline Services Unlimited is 980 Great West Road, Brentford, >> Middlesex TW8 9GS. >> --- >> >> ___ >> 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 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. -o- 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
Re: [Veritas-bu] Fragment size for LTO4 on NBU 6.x
Simon, Yes, the fragment size for the storage unit itself, see my other e-mail. Justin. On Wed, 16 Sep 2009, WEAVER, Simon (external) wrote: > Are we talking about fragment size for the storage unit itself? > Mine is set to the default 1048575MB > > I thought the default would be acceptable for LTO3/ LTO4. (ie: > 1048575MB) > > But happy to hear what others do > Simon > > > > From: veritas-bu-boun...@mailman.eng.auburn.edu > [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Dean > Sent: Wednesday, September 16, 2009 1:59 PM > To: william.d.br...@gsk.com > Cc: veritas-bu@mailman.eng.auburn.edu > Subject: Re: [Veritas-bu] Fragment size for LTO4 on NBU 6.x > > > 20GB here, using IBM 3592. I've considered making the fragment size > larger, but . if it aint broke > > > > On Wed, Sep 16, 2009 at 7:26 PM, wrote: > > > What are people using for the fragment size on LTO4 (or I guess > LTO3) with > NBU 6.x? > > I ask because the default is 1TB, i.e. more or less don't > fragment. > > The argument for a large fragment is that the backup doesn't > have to stop > so often as it does briefly at the end of each fragment to > update the > Master, and also the inter-fragment file markers waste > space..though > that's hardly a consideration on such large tapes now. > > The argument for a small fragment was that the tape can position > at full > speed to the file marker for the appropriate fragment for a > restore, > rather than reading the tar file from the top at read speed, > which for a > large tape could be a very long time. > > We used to (dating back to DLT7000) set a 2GB fragment, as back > then this > was thought a good idea in case you wanted to dd the tape to > disk and read > it without NetBackup. UNIX file systems did not take files > > 2GB. Well I > can't say we ever tried it and it's a silly small size now. > > But what are people using - 100GB? 200GB? Does it really make > a > difference... > > William D L Brown > > > --- > This e-mail was sent by GlaxoSmithKline Services Unlimited > (registered in England and Wales No. 1047315), which is a > member of the GlaxoSmithKline group of companies. The > registered address of GlaxoSmithKline Services Unlimited > is 980 Great West Road, Brentford, Middlesex TW8 9GS. > --- > > ___ > 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. > -o- > 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
Re: [Veritas-bu] Fragment size for LTO4 on NBU 6.x
Are we talking about fragment size for the storage unit itself? Mine is set to the default 1048575MB I thought the default would be acceptable for LTO3/ LTO4. (ie: 1048575MB) But happy to hear what others do Simon From: veritas-bu-boun...@mailman.eng.auburn.edu [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Dean Sent: Wednesday, September 16, 2009 1:59 PM To: william.d.br...@gsk.com Cc: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Fragment size for LTO4 on NBU 6.x 20GB here, using IBM 3592. I've considered making the fragment size larger, but . if it aint broke On Wed, Sep 16, 2009 at 7:26 PM, wrote: What are people using for the fragment size on LTO4 (or I guess LTO3) with NBU 6.x? I ask because the default is 1TB, i.e. more or less don't fragment. The argument for a large fragment is that the backup doesn't have to stop so often as it does briefly at the end of each fragment to update the Master, and also the inter-fragment file markers waste space..though that's hardly a consideration on such large tapes now. The argument for a small fragment was that the tape can position at full speed to the file marker for the appropriate fragment for a restore, rather than reading the tar file from the top at read speed, which for a large tape could be a very long time. We used to (dating back to DLT7000) set a 2GB fragment, as back then this was thought a good idea in case you wanted to dd the tape to disk and read it without NetBackup. UNIX file systems did not take files > 2GB. Well I can't say we ever tried it and it's a silly small size now. But what are people using - 100GB? 200GB? Does it really make a difference... William D L Brown --- This e-mail was sent by GlaxoSmithKline Services Unlimited (registered in England and Wales No. 1047315), which is a member of the GlaxoSmithKline group of companies. The registered address of GlaxoSmithKline Services Unlimited is 980 Great West Road, Brentford, Middlesex TW8 9GS. --- ___ 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. -o- 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
Re: [Veritas-bu] Fragment size for LTO4 on NBU 6.x
32GB here. It all depends how long you want to wait to restore a file if you have large backups that can span a tape completely. With 1TB fragment size, assuming there was no compression and you needed to restore a 10k file at the end of the tape, it would need to read the entire thing to restore the file. If you used a smaller fragement size, it would skip to the closest fragment to the file that needed to be restored. Don't go too small though or every time it writes a file marker, it could slow down the backup. It is all about speed of backup vs. speed of restore (and the data type being backed up/restored) as well. Justin. On Wed, 16 Sep 2009, Dean wrote: > 20GB here, using IBM 3592. I've considered making the fragment size larger, > but . if it aint broke > > > On Wed, Sep 16, 2009 at 7:26 PM, wrote: > >> What are people using for the fragment size on LTO4 (or I guess LTO3) with >> NBU 6.x? >> >> I ask because the default is 1TB, i.e. more or less don't fragment. >> >> The argument for a large fragment is that the backup doesn't have to stop >> so often as it does briefly at the end of each fragment to update the >> Master, and also the inter-fragment file markers waste space..though >> that's hardly a consideration on such large tapes now. >> >> The argument for a small fragment was that the tape can position at full >> speed to the file marker for the appropriate fragment for a restore, >> rather than reading the tar file from the top at read speed, which for a >> large tape could be a very long time. >> >> We used to (dating back to DLT7000) set a 2GB fragment, as back then this >> was thought a good idea in case you wanted to dd the tape to disk and read >> it without NetBackup. UNIX file systems did not take files > 2GB. Well I >> can't say we ever tried it and it's a silly small size now. >> >> But what are people using - 100GB? 200GB? Does it really make a >> difference... >> >> William D L Brown >> >> >> --- >> This e-mail was sent by GlaxoSmithKline Services Unlimited >> (registered in England and Wales No. 1047315), which is a >> member of the GlaxoSmithKline group of companies. The >> registered address of GlaxoSmithKline Services Unlimited >> is 980 Great West Road, Brentford, Middlesex TW8 9GS. >> --- >> >> ___ >> 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] Fragment size for LTO4 on NBU 6.x
20GB here, using IBM 3592. I've considered making the fragment size larger, but . if it aint broke On Wed, Sep 16, 2009 at 7:26 PM, wrote: > What are people using for the fragment size on LTO4 (or I guess LTO3) with > NBU 6.x? > > I ask because the default is 1TB, i.e. more or less don't fragment. > > The argument for a large fragment is that the backup doesn't have to stop > so often as it does briefly at the end of each fragment to update the > Master, and also the inter-fragment file markers waste space..though > that's hardly a consideration on such large tapes now. > > The argument for a small fragment was that the tape can position at full > speed to the file marker for the appropriate fragment for a restore, > rather than reading the tar file from the top at read speed, which for a > large tape could be a very long time. > > We used to (dating back to DLT7000) set a 2GB fragment, as back then this > was thought a good idea in case you wanted to dd the tape to disk and read > it without NetBackup. UNIX file systems did not take files > 2GB. Well I > can't say we ever tried it and it's a silly small size now. > > But what are people using - 100GB? 200GB? Does it really make a > difference... > > William D L Brown > > > --- > This e-mail was sent by GlaxoSmithKline Services Unlimited > (registered in England and Wales No. 1047315), which is a > member of the GlaxoSmithKline group of companies. The > registered address of GlaxoSmithKline Services Unlimited > is 980 Great West Road, Brentford, Middlesex TW8 9GS. > --- > > ___ > 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] Fragment size for LTO4 on NBU 6.x
I'm using a 10G fragment size. Just a guess at a ballpark figure between too small & too large. -M -Original Message- From: veritas-bu-boun...@mailman.eng.auburn.edu [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of william.d.br...@gsk.com Sent: Wednesday, September 16, 2009 3:26 AM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] Fragment size for LTO4 on NBU 6.x What are people using for the fragment size on LTO4 (or I guess LTO3) with NBU 6.x? I ask because the default is 1TB, i.e. more or less don't fragment. The argument for a large fragment is that the backup doesn't have to stop so often as it does briefly at the end of each fragment to update the Master, and also the inter-fragment file markers waste space..though that's hardly a consideration on such large tapes now. The argument for a small fragment was that the tape can position at full speed to the file marker for the appropriate fragment for a restore, rather than reading the tar file from the top at read speed, which for a large tape could be a very long time. We used to (dating back to DLT7000) set a 2GB fragment, as back then this was thought a good idea in case you wanted to dd the tape to disk and read it without NetBackup. UNIX file systems did not take files > 2GB. Well I can't say we ever tried it and it's a silly small size now. But what are people using - 100GB? 200GB? Does it really make a difference... William D L Brown --- This e-mail was sent by GlaxoSmithKline Services Unlimited (registered in England and Wales No. 1047315), which is a member of the GlaxoSmithKline group of companies. The registered address of GlaxoSmithKline Services Unlimited is 980 Great West Road, Brentford, Middlesex TW8 9GS. --- ___ 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] Fragment size for LTO4 on NBU 6.x
New drives are faster. We had replaced the 2GB fragments with 8Gb fragments. -Original Message- From: veritas-bu-boun...@mailman.eng.auburn.edu [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of william.d.br...@gsk.com Sent: Wednesday, September 16, 2009 12:26 PM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] Fragment size for LTO4 on NBU 6.x What are people using for the fragment size on LTO4 (or I guess LTO3) with NBU 6.x? I ask because the default is 1TB, i.e. more or less don't fragment. The argument for a large fragment is that the backup doesn't have to stop so often as it does briefly at the end of each fragment to update the Master, and also the inter-fragment file markers waste space..though that's hardly a consideration on such large tapes now. The argument for a small fragment was that the tape can position at full speed to the file marker for the appropriate fragment for a restore, rather than reading the tar file from the top at read speed, which for a large tape could be a very long time. We used to (dating back to DLT7000) set a 2GB fragment, as back then this was thought a good idea in case you wanted to dd the tape to disk and read it without NetBackup. UNIX file systems did not take files > 2GB. Well I can't say we ever tried it and it's a silly small size now. But what are people using - 100GB? 200GB? Does it really make a difference... William D L Brown --- This e-mail was sent by GlaxoSmithKline Services Unlimited (registered in England and Wales No. 1047315), which is a member of the GlaxoSmithKline group of companies. The registered address of GlaxoSmithKline Services Unlimited is 980 Great West Road, Brentford, Middlesex TW8 9GS. --- ___ 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
