Re: [Veritas-bu] DSU Question.
Given the same senario, if my storage unit is a DSU, will the small backup job go through as there is no tape drive involved. If you've got your DSSU setup to accept more than one stream at a time, yes. Before you get too far into design, you should work out how fast the backups to disk actually are. This can have a big influence on how you use your DSSU. I have a 3TB DSSU, (RAID 6 SATA) and I can't get any better than about 50 MB/sec out of it (usually about 30 MB/sec). I can get the tape drives up to 150 MB/sec. The majority of people seem to think backing up to disk is going to be faster, but that's not necessarily the case. I still direct the majority of backups straight to tape, and use the DSSU for the big long slow ones, like the 1.5 TB Windows client which can only send data to the NBU server at about 15 MB/sec. I send that to disk, so it doesn't hold a tape drive for a day and a half. I also use the DSSU for the backups which don't really have a large amount of data to backup, but need to run and complete fairly quickly, like Oracle archive logs. YMMV. Cheers, Dean On 27/03/2009, at 6:05 PM, dy018 wrote: Hi, I'm still in the mist of a backup design to use either a DSU or a DSSU target for my interim backups. Would like to know if there's a limitation in the number of streams if the storage unit is a DSU? I also assume multiplexing will not be a issue if the target is DSU right? Another senario is, if i were to use backup direct to tape, i have a backup that require to run the bpstart notify script to do some export dump and it might take 30mins or more, the backup will actually hog the drive during the export dump and if there's another small backup that trigger during that time will be put in queue. Given the same senario, if my storage unit is a DSU, will the small backup job go through as there is no tape drive involved. Appreciate anyone of you having such a configuration to share your experiences. Thanks + -- |This was sent by dy_lan...@yahoo.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
[Veritas-bu] Unable to find image in Restore/Catalog
Yes, correct i am looking out for specific date. But when i went in the directory. There are files for that particular date. # pwd /opt/openv/netbackup/db/images/EKMS/123600 # cd .. # ls -ltr total 16 drwxr-xr-x 2 root other512 Mar 6 13:41 123000 drwxr-xr-x 2 root other 1024 Mar 9 13:48 123300 drw-r-xr-x 4 root other 1024 Mar 13 04:44 123600 drwxr-xr-x 2 root other 1024 Mar 22 04:31 123400 drw-r-xr-x 4 root other 1024 Mar 25 02:16 123700 drwxr-xr-x 4 root other 1024 Mar 26 04:34 123500 drwxr-xr-x 2 root other512 Mar 27 16:35 123200 drw-r-xr-x 4 root other512 Mar 28 15:13 123800 # cd 123400 # ls -ltr total 18 -rw--- 1 root other 4040 Feb 14 18:03 EKMS_1234601889_FULL.f -rw-r--r-- 1 root other 4429 Mar 17 16:27 EKMS_1234601889_FULL # cd .. / 123700 # ls -ltr total 16 drwxr-xr-x 2 root other512 Mar 6 13:41 123000 drwxr-xr-x 2 root other 1024 Mar 9 13:48 123300 drw-r-xr-x 4 root other 1024 Mar 13 04:44 123600 drwxr-xr-x 2 root other 1024 Mar 22 04:31 123400 drw-r-xr-x 4 root other 1024 Mar 25 02:16 123700 drwxr-xr-x 4 root other 1024 Mar 26 04:34 123500 drwxr-xr-x 2 root other512 Mar 27 16:35 123200 drw-r-xr-x 4 root other512 Mar 28 15:13 123800 # - I am looking out for 22nd March data. +-- |This was sent by qureshiu...@rediffmail.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
Re: [Veritas-bu] Unable to find image in Restore/Catalog
Please send contents of EKMS_1234601889_FULL This will confirm client and image type. You definitely have a backup - just something wrong with your search criteria why trying to list in BAR. Regards M. -Original Message- From: veritas-bu-boun...@mailman.eng.auburn.edu [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of NBU Sent: 28 March 2009 13:42 To: VERITAS-BU@MAILMAN.ENG.AUBURN.EDU Subject: [Veritas-bu] Unable to find image in Restore/Catalog Yes, correct i am looking out for specific date. But when i went in the directory. There are files for that particular date. # pwd /opt/openv/netbackup/db/images/EKMS/123600 # cd .. # ls -ltr total 16 drwxr-xr-x 2 root other512 Mar 6 13:41 123000 drwxr-xr-x 2 root other 1024 Mar 9 13:48 123300 drw-r-xr-x 4 root other 1024 Mar 13 04:44 123600 drwxr-xr-x 2 root other 1024 Mar 22 04:31 123400 drw-r-xr-x 4 root other 1024 Mar 25 02:16 123700 drwxr-xr-x 4 root other 1024 Mar 26 04:34 123500 drwxr-xr-x 2 root other512 Mar 27 16:35 123200 drw-r-xr-x 4 root other512 Mar 28 15:13 123800 # cd 123400 # ls -ltr total 18 -rw--- 1 root other 4040 Feb 14 18:03 EKMS_1234601889_FULL.f -rw-r--r-- 1 root other 4429 Mar 17 16:27 EKMS_1234601889_FULL # cd .. / 123700 # ls -ltr total 16 drwxr-xr-x 2 root other512 Mar 6 13:41 123000 drwxr-xr-x 2 root other 1024 Mar 9 13:48 123300 drw-r-xr-x 4 root other 1024 Mar 13 04:44 123600 drwxr-xr-x 2 root other 1024 Mar 22 04:31 123400 drw-r-xr-x 4 root other 1024 Mar 25 02:16 123700 drwxr-xr-x 4 root other 1024 Mar 26 04:34 123500 drwxr-xr-x 2 root other512 Mar 27 16:35 123200 drw-r-xr-x 4 root other512 Mar 28 15:13 123800 # - I am looking out for 22nd March data. +-- |This was sent by qureshiu...@rediffmail.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
[Veritas-bu] VMWARE VCB design
I am having some issues in my backups and I think these may be related to LUN ID's mismatch between ESX servers and VCB proxy server. Can anyone here confirm that the LUN numbers seen by ESX hosts must match the LUN numbers on VCB proxy server? If I have 4 ESX hosts, and they have one LUN each (LUN ID 0), how can I present those 4 LUNS, all with LUN ID 0 to the VCB server? TIA ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] DSU Question.
On Sat, Mar 28, 2009 at 1:07 AM, Dean Allen dean.de...@gmail.com wrote: Before you get too far into design, you should work out how fast the backups to disk actually are. This can have a big influence on how you use your DSSU. I have a 3TB DSSU, (RAID 6 SATA) and I can't get any better than about 50 MB/sec out of it (usually about 30 MB/sec). I can get the tape drives up to 150 MB/sec. The majority of people seem to think backing up to disk is going to be faster, but that's not necessarily the case. I concur 100% - this has been our experience as well. SATA drives are cheap, but they're slow. You'll do about half the transactional rate of a good fibre channel or SCSI drive. Many people think that because it's just backups that you can use cheaper SATA drives. It's actually the opposite - backups are the highest I/O generator, by far, in many environments. I still direct the majority of backups straight to tape, and use the DSSU for the big long slow ones, like the 1.5 TB Windows client which can only send data to the NBU server at about 15 MB/sec. I send that to disk, so it doesn't hold a tape drive for a day and a half. For large Windows file systems, we use FlashBackup. We're pushing the larger file systems at 50-60MB/sec now. I also use the DSSU for the backups which don't really have a large amount of data to backup, but need to run and complete fairly quickly, like Oracle archive logs. Absolutely - this is a great use of DSSUs. We'd tried to push everything to DSSUs but this ended up not working for us because of the lousy destage performace we're seeing. We can push a client directly to tape a lot faster than a destage to tape but we don't have enough tape drives to allow the clients to do this within the backup windows. One of these days we'll figure out how to destage with decent performance but so far we haven't been able to figure it out (and neither has Symantec, and not for lack of trying). -- Ed Wilts, Mounds View, MN, USA ewi...@ewilts.org ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] DSU Question.
On Sat, 28 Mar 2009 09:55:04 -0500 Ed Wilts ewi...@ewilts.org wrote: On Sat, Mar 28, 2009 at 1:07 AM, Dean Allen dean.de...@gmail.com wrote: Before you get too far into design, you should work out how fast the backups to disk actually are. This can have a big influence on how you use your DSSU. I have a 3TB DSSU, (RAID 6 SATA) and I can't get any better than about 50 MB/sec out of it (usually about 30 MB/sec). I can get the tape drives up to 150 MB/sec. The majority of people seem to think backing up to disk is going to be faster, but that's not necessarily the case. I concur 100% - this has been our experience as well. SATA drives are cheap, but they're slow. You'll do about half the transactional rate of a good fibre channel or SCSI drive. Many people think that because it's just backups that you can use cheaper SATA drives. It's actually the opposite - backups are the highest I/O generator, by far, in many environments. This really depends on the controller in use. There are controllers out there that will do 400MB/s or faster. We have 3ware and Areca controllers that do just this. This allows us to use multiple FULL gigabit connections in from clients as well as stage to multiple LTO3 tape drives at the same time using one media server. --andy. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Veritas-bu] Unable to find image in Restore/Catalog
Yes, correct i am looking out for specific date. But when i went in the directory. There are files for that particular date. # pwd /opt/openv/netbackup/db/images/EKMS/123600 # cd .. # ls -ltr total 16 drwxr-xr-x 2 root other512 Mar 6 13:41 123000 drwxr-xr-x 2 root other 1024 Mar 9 13:48 123300 drw-r-xr-x 4 root other 1024 Mar 13 04:44 123600 drwxr-xr-x 2 root other 1024 Mar 22 04:31 123400 drw-r-xr-x 4 root other 1024 Mar 25 02:16 123700 drwxr-xr-x 4 root other 1024 Mar 26 04:34 123500 drwxr-xr-x 2 root other512 Mar 27 16:35 123200 drw-r-xr-x 4 root other512 Mar 28 15:13 123800 # cd 123400 # ls -ltr total 18 -rw--- 1 root other 4040 Feb 14 18:03 EKMS_1234601889_FULL.f -rw-r--r-- 1 root other 4429 Mar 17 16:27 EKMS_1234601889_FULL # cd .. / 123700 # ls -ltr total 16 drwxr-xr-x 2 root other512 Mar 6 13:41 123000 drwxr-xr-x 2 root other 1024 Mar 9 13:48 123300 drw-r-xr-x 4 root other 1024 Mar 13 04:44 123600 drwxr-xr-x 2 root other 1024 Mar 22 04:31 123400 drw-r-xr-x 4 root other 1024 Mar 25 02:16 123700 drwxr-xr-x 4 root other 1024 Mar 26 04:34 123500 drwxr-xr-x 2 root other512 Mar 27 16:35 123200 drw-r-xr-x 4 root other512 Mar 28 15:13 123800 # - I am looking out for 22nd March data. # /usr/openv/netbackup/bin/bpdbm -ctime 123700 123700 = Fri Mar 13 23:06:40 2009 # /usr/openv/netbackup/bin/bpdbm -ctime 123800 123800 = Wed Mar 25 12:53:20 2009 # Any March 22 backup will be in the 123700 directory. If you intended to list that directory with the cd .. / 123700, you didn't. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] DSU Question.
It really does come down to the nature of SATA. In larger arrays the controllers can easily outrun the disk. I've done extensive testing around backups to SATA (mostly in a VTL config, but basic disk works just the same). What I generally see is the following. Say I have 4 SATA LUNs on 4 different raid groups. Next I create 4 virtual tapes on each of those LUNs. I start one dd /dev/zero copy to the first tape on the first LUN, I see approx 50MB/s - that's the peak transfer rate per LUN. I start a second dd to the first tape on the second LUN, I see an additional 50MB/s. Start the other two to the other two LUNs and I get an aggregate of 200MB/s. Now I add another copy to the second tape on each of LUNs and rather than seeing an aggregate increase in speed above and beyond that 200MB/s I had I actually see a drop in overall speed. Bottom line is the nature of SATA is that it tanks under random IO, it is best suited for sequential. Many folks think backup is sequential and they are right, when you consider one backup. Once you get many backups running concurrently you approach a very random IO pattern and SATA hates that. I've seen an array peak at 800MB/s using one backup per LUN (which was set up as one LUN per RAID group). That's the controller peak capability. That same array gives me around 250MB/s on average each night when there are 70-80 concurrent streams hitting it. -mike -Original Message- From: veritas-bu-boun...@mailman.eng.auburn.edu [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Andrew Sydelko Sent: Saturday, March 28, 2009 12:37 PM To: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] DSU Question. On Sat, 28 Mar 2009 09:55:04 -0500 Ed Wilts ewi...@ewilts.org wrote: On Sat, Mar 28, 2009 at 1:07 AM, Dean Allen dean.de...@gmail.com wrote: Before you get too far into design, you should work out how fast the backups to disk actually are. This can have a big influence on how you use your DSSU. I have a 3TB DSSU, (RAID 6 SATA) and I can't get any better than about 50 MB/sec out of it (usually about 30 MB/sec). I can get the tape drives up to 150 MB/sec. The majority of people seem to think backing up to disk is going to be faster, but that's not necessarily the case. I concur 100% - this has been our experience as well. SATA drives are cheap, but they're slow. You'll do about half the transactional rate of a good fibre channel or SCSI drive. Many people think that because it's just backups that you can use cheaper SATA drives. It's actually the opposite - backups are the highest I/O generator, by far, in many environments. This really depends on the controller in use. There are controllers out there that will do 400MB/s or faster. We have 3ware and Areca controllers that do just this. This allows us to use multiple FULL gigabit connections in from clients as well as stage to multiple LTO3 tape drives at the same time using one media server. --andy. ___ 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] Fwd: DSU Question.
On Sun, Mar 29, 2009 at 4:36 AM, Andrew Sydelko and...@sydelko.org wrote: On Sat, 28 Mar 2009 09:55:04 -0500 Ed Wilts ewi...@ewilts.org wrote: On Sat, Mar 28, 2009 at 1:07 AM, Dean Allen dean.de...@gmail.com wrote: Before you get too far into design, you should work out how fast the backups to disk actually are. This can have a big influence on how you use your DSSU. I have a 3TB DSSU, (RAID 6 SATA) and I can't get any better than about 50 MB/sec out of it (usually about 30 MB/sec). I can get the tape drives up to 150 MB/sec. The majority of people seem to think backing up to disk is going to be faster, but that's not necessarily the case. I concur 100% - this has been our experience as well. SATA drives are cheap, but they're slow. You'll do about half the transactional rate of a good fibre channel or SCSI drive. Many people think that because it's just backups that you can use cheaper SATA drives. It's actually the opposite - backups are the highest I/O generator, by far, in many environments. This really depends on the controller in use. There are controllers out there that will do 400MB/s or faster. We have 3ware and Areca controllers that do just this. This allows us to use multiple FULL gigabit connections in from clients as well as stage to multiple LTO3 tape drives at the same time using one media server. This is an HDS AMS 1000. I know the controller is capable of more throughput. The bottleneck seems to be the number of back end fibre loops, of which there are only 2. Another problem is that I am sharing both loops/disk trays with Enterprise Vault for Exchange, which is constantly dribbling at the disk. If we added more disk trays, the throughput would theoretically increase relative to the number of trays. To get performance close to a tape drive, I guesstimate I'd need 6 drive trays, which would give me about 50TB of usable space. But I don't need that much - I'd prefer to have 1TB of fast FC drives on the USPV, which is a whole different kettle of fish. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Slow Informix Logs backups
I agree with the DSU suggestion -- this is exactly the reason we use that method with an Informix DB here. Waiting for tape to do these backups just isn't fast enough. The DSU solves this problem completely. -Original Message- From: veritas-bu-boun...@mailman.eng.auburn.edu [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Justin Piszcz Sent: Friday, March 27, 2009 4:48 PM To: Larry Mascarenhas Cc: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Slow Informix Logs backups On Fri, 27 Mar 2009, Larry Mascarenhas wrote: Hello, I'm running backups on Informix7 DBs. We're able to stream the DB backups using parallelism 4 and get good throughput (100MB/s, yes megabytes/sec, it is a SAN Media Server). A 300Gig DB takes less than 1 hour. However (I know ;)), when it backs up the LOGS (all backups go to tape, I don't have Disk backups), each log comes in as a separate request. Each log is therefore a separate job. So the time taken to process this request is greater than the time to backup each log. ie each log is 100MB and the time taken is 2secs (when the resource is allocted and ready), but it takes 1+min to create the job/assign the resource/and begin writing. This is resulting in my never being able to catch up with the rate of logs generation although the amount to be backed up is minimal eg 30logs is just 3Gig, but takes approx 30mins and by that time 10 more logs are created. I am using media_unmount_delay so the tapes are not re-mounting for every request. I cannot increase the size of the LOGS as this would affect replication and recoverability (double whammy). This is Symantec's recommendation. I'm looking for experiences that people have had to speed up the Informix backups. Thanks. -- Larry Mascarenhas lmasc...@comcast.net ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu Why not use a Disk Staging Unit if the logs are small enough? Send to disk first - then shoot to tape? Justin. ___ 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] Vaulting from disk storage groups
Hi Guys, Can someone please explain the best way to vault from disk storage units? I have got a 5 media servers enabled with the advanced disk option, all with local disk, contained within a storage unit group. I have also got the media servers connect to multiple tape drives with SSO. The backup images will be spread over all storage units. My question is about vaulting from the disk storage unit to tape. When configuring the vault profile to vault to tape, should I point the source at the disk storage unit (as you cant point directly to Storage unit group), and the destination to the tape storage group? Or, point the vault to all storage units, and destination to individual tape drives connected to the media servers? I am running 6.5.3. Any help appreciated Jai +-- |This was sent by georgeandsyl...@iinet.net.au 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
