Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

Examples of how to use new_stream

Created: 04 Apr 2013 • Updated: 10 Apr 2013 | 24 comments
This issue has been solved. See solution.

I have a Windows 2008 R2 server with two drives (C & E) and a HP 2 drive MSL4048 library.

I would like to backup up the E drive using both drives that are in the MSL4048 library to improve backup performance (reduce the time needed to back it up). 

I tried the following in my Daily Backup policy (which is Full / Incremental):

NEW_STREAM
E:\Directory1
E:\Directory2
NEW_STREAM
E:\Directory3
E:\Directory4
etc...

When the Full backup portion of the policy ran, I only got the 2nd stream in my backup (ie. E:\Directory3, E:\Directory4, etc...) Nothing from the 1st stream.

What am I missing? Am I trying to do something that is not allowed because it is on a single drive?

Can someone send me a link with examples on how to use the NEW_STREAM directive? I read the Admin manual and it looked straight forword.

Thanks in advance.



 

Operating Systems:

Comments 24 CommentsJump to latest comment

Marianne's picture

That is exactly how I use NEW_STREAM.

Important to ensure that 'Allow multiple data streams' is selected in attributes.

It is also important to make this change when Full schedule is due to prevent Incrementals from running as Full.

Have you perhaps checked with 'nbpemreq -predict ....' to ensure that policy shows 2 streams?

Was a parent and a child stream started for this backup or just a single job?

Can you please check if any STREAMS files were created under client's images folder on the master?

 

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

BigMo's picture

Marianne,

This may have more to do with my lack of understanding how Netbackup 7.5 works rather than a lack of understanding about NEW_STREAMS.
 

Yes, Allow multiple data streams is selected. Limit jobs per policy is not (meaning unlimited). I have 2 storage units that the NetBackup Wizard added, <ServerName>-hcart3 and <ServerName>-hcart3-robot-tld-1. Both are set to Enable Multiplexing with 2 max concurrent write drives and 4 max streams per drive.
 

After further review, I noticed that both parts of my Daily Backup policy (Incremental and Full) ran at the same time:
(Note: I took the default policy items when I created the Daily Backup policy which includes 2 schedules, a incremental and a full. This may be the real source of my problem. Initially I tried to create just an incremental backup job but it would not run and complained about not having a full backup.)

1044 Backup Done 0 Daily_Backup Full  <client> <media server> 4/3/2013 10:00:13 PM 4/4/2013 3:26:46 AM 05:26:33 904179080 788026
1043 Backup Done 0 Daily_Backup Cumulative-Inc <client> <media server> 4/3/2013 10:00:13 PM 4/3/2013 10:04:16 PM 00:04:03 4539848 6
1042 Backup Done 0 Daily_Backup -  <client> <media server> 4/3/2013 10:00:00 PM 4/4/2013 3:26:56 AM 05:26:56 

From looking at the details of each job it looks like NEW_STREAM one did an incremental backup of directories 1 & 2 and NEW_STREAM two did a
full backup of directories 3,4,5 etc.
That is NOT what I expected. I expected tape drive 1 to service NEW_STREAM 1 and tape drive 2 to service NEW_STREAM 2.

 
Here is a copy of my Daily_Backup Streams file from the images dir.

T 0 0
1 0 Daily_Backup Full 0,0,604800 0 0 E:\directory1
1 0 Daily_Backup Full 0,0,604800 0 0 E:\directory2
2 1365041048 Daily_Backup Full 0,0,604800 0 0 E:\directory3
2 1365041048 Daily_Backup Full 0,0,604800 0 0 E:\directory4
2 1365041048 Daily_Backup Full 0,0,604800 0 0 E:\directory5
2 1365041048 Daily_Backup Full 0,0,604800 0 0 E:\directory6
2 etc...
1 1365040813 Daily_Backup Cumulative-Inc 4,0,86400 0 0 E:\directory1
1 1365040813 Daily_Backup Cumulative-Inc 4,0,86400 0 0 E:\directory2
2 0 Daily_Backup Cumulative-Inc 4,0,86400 0 0 E:\directory3
2 0 Daily_Backup Cumulative-Inc 4,0,86400 0 0 E:\directory4
2 0 Daily_Backup Cumulative-Inc 4,0,86400 0 0 E:\directory5
2 etc...

This looks like what I expected (tape drive 1 to service NEW_STREAM 1 and tape drive 2 to service NEW_STREAM 2)
I didn't expect both schedules to run.  The policy had just the E:\ listed before I started using the NEW_STREAM directive and the full backup would run weekly and the incremental ran the other days. Never simultaneously.

Thanks for your prompt and insightful comments.

Marianne's picture

I noticed that both parts of my Daily Backup policy (Incremental and Full) ran at the same time

This should not have happened.

Please show us your Policy config with this command on the Master:

bppllist <policy-name> -U

as well as recent backup details for this client:

bpimagelist -client <client-name> -d 04/01/2013 -U

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

BigMo's picture

VxSS authentication failed (116) when I ran bppllist <policy-name> -U

and VxSS authentication failed with bpimagelist -client <client-name> -d 04/01/2013 -U

Not sure what to do next. Have a great weekend.

Thanks... Look forward to your reply.

Marianne's picture

Seems you have NBAC configured?

You will need to 'login' before running NBU commands:

bpnbat -login

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

BigMo's picture

Yes, I have NBAC configured but have never used it so I am extremely unfamiliar with it. I hope to  use it to configure an end user for restores (and only restores).

On to your previous questions:

C:\Program Files\Veritas\NetBackup\bin\admincmd>bppllist -U
Policy:            1Manual_Backup
Policy:            CDriveBackup
Policy:            Catalog_Backup
Policy:            Daily_Backup
Policy:            LMS_Archive
Policy:            Monthly_Backup
Policy:            Weekly_Backup

C:\Program Files\Veritas\NetBackup\bin\admincmd>bpimagelist -client client-name -d 04/01/2013 -U

Backed Up         Expires       Files       KB  C  Sched Type   On Hold Index Status Policy
----------------  ---------- -------- --------  -  ------------ ------- ------------ ------------
04/08/2013 04:03  INFINITY       1643  1764466  N  Full Backup  0       0            Catalog_Backup
04/08/2013 04:01  INFINITY         15   236076  N  Full Backup  0       0            Catalog_Backup
04/07/2013 22:03  04/13/2013     1639 13355481  N  Cumulative I 0       0            Daily_Backup
04/07/2013 16:35  INFINITY       1663  1764119  N  Full Backup  0       0            Catalog_Backup
04/07/2013 16:32  INFINITY         15   236080  N  Full Backup  0       0            Catalog_Backup
04/06/2013 22:00  05/02/2013   850305 3671528133  Y  Full Backup  0       0            Weekly_Backup
04/06/2013 04:04  INFINITY       1636  1769114  N  Full Backup  0       0            Catalog_Backup
04/06/2013 04:01  INFINITY         15   236076  N  Full Backup  0       0            Catalog_Backup
04/05/2013 22:03  04/11/2013     1488 10376952  N  Cumulative I 0       0            Daily_Backup
04/05/2013 20:44  04/11/2013     1485 10312629  N  Cumulative I 0       0            Daily_Backup
04/05/2013 20:36  INFINITY       1656  1768575  N  Full Backup  0       0            Catalog_Backup
04/05/2013 20:34  INFINITY         15   236080  N  Full Backup  0       0            Catalog_Backup
04/04/2013 22:00  04/10/2013    63834 4056409943  N  Full Backup  0       0            Daily_Backup
04/04/2013 04:03  INFINITY       1635  1864068  N  Full Backup  0       0            Catalog_Backup
04/04/2013 04:01  INFINITY         15   236076  N  Full Backup  0       0            Catalog_Backup
04/03/2013 22:04  04/09/2013   788026 904179080  N  Full Backup  0       0            Daily_Backup
04/03/2013 22:00  04/09/2013        6  4539848  N  Cumulative I 0       0            Daily_Backup
04/03/2013 08:04  INFINITY       1648  1767957  N  Full Backup  0       0            Catalog_Backup
04/03/2013 08:02  INFINITY         15   236516  N  Full Backup  0       0            Catalog_Backup
04/03/2013 07:20  04/09/2013    35287 55631651  N  Cumulative I 0       0            Daily_Backup
04/03/2013 04:02  INFINITY       1561  1763355  N  Full Backup  0       0            Catalog_Backup
04/03/2013 04:00  INFINITY         15   235688  N  Full Backup  0       0            Catalog_Backup
04/02/2013 22:00  04/08/2013    35246 47576549  N  Cumulative I 0       0            Daily_Backup
04/02/2013 12:09  INFINITY       1554  1758972  N  Full Backup  0       0            Catalog_Backup
04/02/2013 11:51  INFINITY         16   236391  N  Full Backup  0       0            Catalog_Backup
04/02/2013 11:04  INFINITY       1545  1758732  N  Full Backup  0       0            Catalog_Backup
04/02/2013 10:58  INFINITY         16   235707  N  Full Backup  0       0            Catalog_Backup
04/01/2013 16:34  04/27/2013   852446 3695707291  Y  Full Backup  0       0            Weekly_Backup

Thanks (and a special Thanks for tolerating my ignorance....)

Rusty Major's picture

Without being able to see what your policy looks like, I would hazard a guess that they are running concurrently because the windows for both schedules are not exactly the same. Take a look at these and make sure they overlap at the same exact times, otherwise you can have situations where you do have an INC and a Full running at the same time on the same day.

BigMo's picture

There are 2 schedules inside my Daily_Backup policy (Incremental & Full) both start at 10PM and close at 4AM

I couldn't figure out how to get an export from the GUI policy so I ran you a bppllist Daily_Backup -L. Don't know if this info will help...
Policy Name:       Daily_Backup
Options:           0x0
template:          FALSE
audit_reason:         ?
Names:             (none)
Policy Type:       MS-Windows (13)
Active:            yes
Effective date:    08/11/2011 06:48:50
Client Compress:   no
Follow NFS Mnts:   yes
Backup netwrk drvs:yes
Collect TIR info:      no
Mult. Data Stream: yes
Perform Snapshot Backup:   no
Snapshot Method:           (none)
Snapshot Method Arguments: (none)
Perform Offhost Backup:    no
Backup Copy:               0
Use Data Mover:            no
Data Mover Type:           2
Use Alternate Client:      no
Alternate Client Name:     (none)
Use Virtual Machine:      0
Hyper-V Server Name:     (none)
Enable Instant Recovery:   no
Policy Priority:   0
Max Jobs/Policy:   12
Disaster Recovery: 0
Collect BMR Info:  no
Keyword:           (none specified)
Data Classification:       -
Residence is Storage Lifecycle Policy:    no
Client Encrypt:    no
Checkpoint:        no
Residence:         <ServerName>-hcart3-robot-tld-1
Volume Pool:       Daily
Server Group:      *ANY*
Granular Restore Info:  no
Exchange Source attributes:              no
Exchange 2010 Preferred Server: (none defined)
Application Discovery:      no
Discovery Lifetime:      28800 seconds
ASC Application and attributes: (none defined)
Generation:      42
Ignore Client Direct:  no
Enable Metadata Indexing:  no
Index server name:  NULL
Use Accelerator:  no
Client/HW/OS/Pri/DMI:   <Server+DomainName> Windows-x64 Windows2008 0 0 0 0 ?
Include:           NEW_STREAM
Include:           E:\directory1
Include:           E:\directory2
Include:           NEW_STREAM
Include:           E:\directory3
Include:           E:\directory4
Include:           E:\directory5
Include:           etc...
Schedule:              Full
  Type:                FULL (0)
  Frequency:           7 day(s) (604800 seconds)
    EXCLUDE DATE 0 - <List of Exclude Dates>
  Maximum MPX:         1
  Synthetic:           0
  Checksum Change Detection: 0
  PFI Recovery:        0
  Retention Level:     0 (144 hours)
  u-wind/o/d:          0 0
  Incr Type:           DELTA (0)
  Alt Read Host:       (none defined)
  Max Frag Size:       0 MB
  Number Copies:       1
  Fail on Error:       0
  Residence:           (specific storage unit not required)
  Volume Pool:         (same as policy volume pool)
  Server Group:        (same as specified for policy)
  Residence is Storage Lifecycle Policy:         0
  Schedule indexing:     0
  Daily Windows:
   Day         Open       Close       W-Open     W-Close
   Sunday      022:00:00  028:00:00   022:00:00  028:00:00 
   Monday      022:00:00  028:00:00   046:00:00  052:00:00 
   Tuesday     022:00:00  028:00:00   070:00:00  076:00:00 
   Wednesday   022:00:00  028:00:00   094:00:00  100:00:00 
   Thursday    022:00:00  028:00:00   118:00:00  124:00:00 
   Friday      022:00:00  028:00:00   142:00:00  148:00:00 
   Saturday    022:00:00  028:00:00   166:00:00  172:00:00 004:00:00
Schedule:              Cumulative-Inc
  Type:                CINC (4)
  Frequency:           1 day(s) (86400 seconds)
    EXCLUDE DATE 0 - <List of Exclude Dates>
  
  Maximum MPX:         1
  Synthetic:           0
  Checksum Change Detection: 0
  PFI Recovery:        0
  Retention Level:     0 (144 hours)
  u-wind/o/d:          0 0
  Incr Type:           DELTA (0)
  Alt Read Host:       (none defined)
  Max Frag Size:       0 MB
  Number Copies:       1
  Fail on Error:       0
  Residence:           (specific storage unit not required)
  Volume Pool:         (same as policy volume pool)
  Server Group:        (same as specified for policy)
  Residence is Storage Lifecycle Policy:         0
  Schedule indexing:     0
  Daily Windows:
   Day         Open       Close       W-Open     W-Close
   Sunday      022:00:00  028:00:00   022:00:00  028:00:00 
   Monday      022:00:00  028:00:00   046:00:00  052:00:00 
   Tuesday     022:00:00  028:00:00   070:00:00  076:00:00 
   Wednesday   022:00:00  028:00:00   094:00:00  100:00:00 
   Thursday    022:00:00  028:00:00   118:00:00  124:00:00 
   Friday      022:00:00  028:00:00   142:00:00  148:00:00 
   Saturday    000:00:00  000:00:00
 

Andy Welburn's picture

Two changes I would make, which may or may not help you resolve some of your issues.

 

I presume from the fact that the frequencies you have set that you want to run the incrementals daily (exc Saturday) & the fulls once a week? (sorry, don't like -L on bppllist for working out backup windows -U is much friendlier!!)

In which case:

  1. make sure your backup windows *only* open on the day(s) you want (i.e. it looks like your full schedules have windows open every day)
  2. make your frequency less than 1 day for your incrementals & less than 7 days for your fulls e.g. you could essentially get away with a frequency of 7 hours for both (just larger than your backup window) - this would stop any possible 'schedule creep'.

Other than that your settings for streams etc seem ok at first glance.

***EDIT***

Making those frequency changes should also allow you more leeway to re-run failed jobs or test changes without them affecting when your scheduled jobs actually start.

BigMo's picture

Marianne asked for the bppllist -U and I forgot to put the policy name in the string. Here is the -U for your reference. 

You may want to review my other comments on how this policy is running. When the full daily backup runs it only does the 2nd stream not the first. I want both streams to run and use both drives to reduce the backup time, but that is not happening. The incremental are working the way I want but not the full.  I have not clue as to why.

I also noticed my Weekly backup with 2 streams (c:\ & e:\) ran only the 1st stream (e:\) on 4-6 but not the 2nd stream (c:\). On 4-8 it backed up the 2nd stream (c:\) but not the 1st stream (e:\) - Looks like I don't understand quite a bit. Note: 4-6 Weekly backup was re-run because of no window available on the original date.

I have adjusted the Daily_Backup to reflect your suggestions.

What Marianne Asked for.... Policy Name:       Daily_Backup

  Policy Type:         MS-Windows
  Active:              yes
  Effective date:      08/11/2011 06:48:50
  Backup network drvs: yes
  Collect TIR info:    no
  Mult. Data Streams:  yes
  Client Encrypt:      no
  Checkpoint:          no
  Policy Priority:     0
  Max Jobs/Policy:     12
  Disaster Recovery:   0
  Collect BMR info:    no
  Residence:           <Server>-hcart3-robot-tld-1
  Volume Pool:         Daily
  Server Group:        *ANY*
  Keyword:             (none specified)
  Data Classification:       -
  Residence is Storage Lifecycle Policy:    no
  Application Discovery:      no
  Discovery Lifetime:      28800 seconds
ASC Application and attributes: (none defined)

  Granular Restore Info:  no
  Ignore Client Direct:  no
Enable Metadata Indexing:  no
Index server name:  NULL
  Use Accelerator:  no
  HW/OS/Client:  Windows-x64   Windows2008   <Server FQDN>

  Include:  NEW_STREAM
            E:\Directory1
            E:\Directory2
            NEW_STREAM
            E:\Directory3
            E:\Directory4
            E:\Directory5
            E:\ etc...

  Schedule:              Full
    Type:                Full Backup
    Frequency:           every 7 days
    Maximum MPX:         1
    Synthetic:           0
    Checksum Change Detection: 0
    PFI Recovery:        0
    Retention Level:     0 (144 hours)
    Number Copies:       1
    Fail on Error:       0
    Residence:           (specific storage unit not required)
    Volume Pool:         (same as policy volume pool)
    Server Group:        (same as specified for policy)
      EXCLUDE DATE 0 - 01/05/2013
      EXCLUDE DATE 1 - etc...
    Residence is Storage Lifecycle Policy:         0
    Schedule indexing:     0
    Daily Windows:
          Sunday     22:00:00  -->  Monday     04:00:00
          Monday     22:00:00  -->  Tuesday    04:00:00
          Tuesday    22:00:00  -->  Wednesday  04:00:00
          Wednesday  22:00:00  -->  Thursday   04:00:00
          Thursday   22:00:00  -->  Friday     04:00:00
          Friday     22:00:00  -->  Saturday   04:00:00
          Saturday   22:00:00  -->  Sunday     04:00:00

  Schedule:              Cumulative-Inc
    Type:                Cumulative Incremental Backup
    Frequency:           every 1 day
    Maximum MPX:         1
    Synthetic:           0
    Checksum Change Detection: 0
    PFI Recovery:        0
    Retention Level:     0 (144 hours)
    Number Copies:       1
    Fail on Error:       0
    Residence:           (specific storage unit not required)
    Volume Pool:         (same as policy volume pool)
    Server Group:        (same as specified for policy)
      EXCLUDE DATE 0 - 01/05/2013
      EXCLUDE DATE 1 - etc...
 
    Residence is Storage Lifecycle Policy:         0
    Schedule indexing:     0
    Daily Windows:
          Sunday     22:00:00  -->  Monday     04:00:00
          Monday     22:00:00  -->  Tuesday    04:00:00
          Tuesday    22:00:00  -->  Wednesday  04:00:00
          Wednesday  22:00:00  -->  Thursday   04:00:00
          Thursday   22:00:00  -->  Friday     04:00:00
          Friday     22:00:00  -->  Saturday   04:00:00
          Saturday   22:00:00  -->  Sunday     04:00:00

 

Andy Welburn's picture

I also noticed my Weekly backup with 2 streams (c:\ & e:\) ran only the 1st stream (e:\) on 4-6 but not the 2nd stream (c:\). On 4-8 it backed up the 2nd stream (c:\) but not the 1st stream (e:\) - Looks like I don't understand quite a bit. Note: 4-6 Weekly backup was re-run because of no window available on the original date.

This *could* be due to the frequency & backup windows you have - if you manually re-ran a full mid-week & cancelled one stream or one failed during 'testing' then the successful would not run until 7 days had passed whereas the other would run 7 days after its last successful run. I say *could* as it is feasible & I don't know what has been done when & I daresay if you've been fighting with this over the past week or so you may feel the same - maybe!

As I mentioned earlier, with your MPX & multistream settings in policy & STU, I cannot see why you should not get the results you desire. Maybe time to start afresh with a new policy with new backup windows & frequencies & a restricted set of backup selections for testing purposes, get the fulls to work as expected (again can't see why the wouldn't) & then the incrementals.

The reason I say you should get the results you desire is:

The incremental are working the way I want but not the full.

- so your config *does* appear to be correct, it could just be the windows/frequencies/manual backups/failed jobs etc etc etc that are confusing the issue.

Rusty Major's picture

@Andy, I won't say I disagree with the frequency and window setting changes you recommended, but there is nothing wrong with the way mmoulton has them currently configured. I actually prefer to schedule backups the mmoulton has them so that I never have to worry about a weekly full backup failing the one day it's scheduled and not getting a chance to run until the following week. With this setting it will continue to try to run the full each day until it is successful and then revert back to the shorter frequency backup.

 

Based on what you're saying, mmoulton, it looks like the policy is keeping track of when each stream has run and NetBackup doesn't do that within the file list level. I have two suggestions you can try:

1) Run a manual full backup and make sure both of the streams kick off.

2) Delete the policy and create it again.

I want to clarify that the first stream isn't queued up at all, right? If it's queued and only one stream is running at a time, then it would be a storage unit setting too low for the number of drives you have.

Andy Welburn's picture

I actually prefer to schedule backups the mmoulton has them so that I never have to worry about a weekly full backup failing the one day it's scheduled and not getting a chance to run until the following week. With this setting it will continue to try to run the full each day until it is successful and then revert back to the shorter frequency backup.

Confused? Not sure I follow how a 7 day frequency job with a 6 hour window each & every day will achieve this?

*Edit*

I *can* see how it has the opportunity to run on a Sunday, say, if it failed miserably each time during the Saturday window, but how will it run the following Saturday if the frequency is 7 days?

Rusty Major's picture

You have one schedule for your Incrementals and one schedule for your Fulls. The Incremental has a 1 day frequency and the Full has a 1 week frequency. Both of them have a window that is exactly the same. Due to the scheduling algorithm and the fact that if two schedules are due at the same time, the one with the longer frequency will win allows this to happen.

 

It's a lot more complicated than this and there are many things that go into determining schedules, but at a very high level, that's how it works.

Andy Welburn's picture

I understand that, but revert to my original question with a little addition:

I *can* see how it (the FULL) has the opportunity to run on a Sunday, say, if it failed miserably each time during the Saturday window, but how, once it has run on the Sunday, will it run the following Saturday if the frequency is 7 days?

Rusty Major's picture

It won't. It will run 7 days later, as dictated by the frequency, which in this case will be the next Sunday. But that goes back to my point where if you aren't restricted to running full backups on the weekend or other days, this won't matter. I actually feel more comfortable with this method because I know the full (or monthly or yearly) will run so we aren't chasing making sure these fulls run if they are scheduled only on certain days.

Andy Welburn's picture

Understood - now!

 

It's amazing how 'blinkered' you (i.e. me) can get just relating set-ups to your own...

Rusty Major's picture

@mmoulton

I was incorrect on NBU keeping track of the streams. This note taken from page 668 of the Unix Admin Guide I clears up what is happening:

Multistreaming jobs:

Each stream is scheduled independently. The data may
change in the time between the streamed backups. Two
restores that are based on the same backup may not be
identical if created from different streams.
Multistreaming jobs

So since you ran it manually some time earlier, that schedule got pushed out later.

Marianne's picture

@mmoulton - pleas have a look at this article to understand how a manual backup or 'schedule creeping' can affect the timing of frequency backups:

https://www-secure.symantec.com/connect/articles/netbackup-frequency-based-scheduling

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

BigMo's picture

All,

Thanks so much for every ones help, especially Marianne. 

As it turns out, streams were the least problem. It was various items including lack of understanding on how NetBackup works in general.  The final solution to my problem was to configure the Host Properties -> Global Attributes -> Max Jobs per Client from a default value of 1 to 4 and Host Properties -> Client Attributes -> Max Data Streams from default of 1 to 4.  Both drives, inside of the MSL4048, are now servicing each stream and my backup times have been reduced by over 50%.  The knowledge you have shared with me will enhance the further reduction in my backup times. 

Not sure who should get credit for the solution but my problem is offically resolved.

Thanks again... 

SOLUTION
Andy Welburn's picture

Glad you got it sorted.

Looking back at all the posts, it looks like we didn't actually cover the settings you amended - which is suprising as they're usually 2 of about 6 settings we would normally ask you to check!

sabby's picture

@mmoulton

Reading your query above,

"I would like to backup up the E drive using both drives that are in the MSL4048 library to improve backup performance (reduce the time needed to back it up)."

You are trying to reduce the backup time using the multistreaming feature by splitting your E drive directories into two different streams. I dont know how is the backup time been reduced by over 50% (dont know what directives you were using earlier to backup your C: and E:) but this whole thing takes me to the "backup selection tab" chapter of the admin guide which says that its not recommended to use multiple concurrent streams to backup one physical disk.

Quote from Admin guide:

"Note: For best performance, use only one data stream to back up each physical
device on the client. Multiple concurrent streams from a single physical device
can cause longer backup times. The disk heads must move back and forth between
the tracks that contain files for the respective streams."

I know this post has been resolved but would like to have clear idea on this from everybody involved in this post.

Regards,

Sahil Bhatia

 

Andy Welburn's picture

"Note: For best performance, use only one data stream to back up each physical
device on the client. Multiple concurrent streams from a single physical device
can cause longer backup times. The disk heads must move back and forth between
the tracks that contain files for the respective streams."

A very good point.

At the end of the day it's often a judgement call & balancing act. Obviously each backup is accessing the same drive at the same time so this will affect performance, but it can be found that splitting a backup up in this way can reduce overall backup times

e.g.

A backup of one drive in full could maybe take 10 hours.

Split into 2 streams, each stream to run concurrently takes 8 hours - saving 2 hours altho' looked at individually this could be seen to take 6 hours longer!

 

I must admit, we seldom split backups for individual drives on servers as the amount of data did not necessitate it. The only time we really took advantage of multiple streams in this way was when the underlying storage was a filer therefore each 'drive' or 'filesystem' was composed of many spindles or disks so this read contention was not so much of an issue.

 

 

Marianne's picture

@sabby, this is true when it is a single hard drive.
When the drive is a lun on a hardware raid, it is normally striped across multiple physical disks.
Multiple data streams off the same drive is fine in this instance.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links