Hi Guru's,

Can someone please tell me if this is normal or else give me clues as
to what the possible problem is.

I have a v240 that is backing up to a HP LTO3 tape drive via its
onboard scsi port and I am getting transfer rates of between 9.5mb per
sec (for root) up to 27mb per sec for a database file system.

Backup Command is

/usr/sbin/ufsdump 0uf /dev/rmt/0cbn /

Backup Tape Drive

mt -f /dev/rmt/0cbn status

HP Ultrium LTO 3 tape drive:
   sense key(0x0)= No Additional Sense   residual= 0   retries= 0
   file no= 0   block no= 0

I then take that tape to another site with a v240 with equivalent cpu
and memory config with a Sun badged HP LTO3 connected via its internal
scsi card, boot from cdrom (latest sol 9hw) and get transfer rates of
approx 1.2mb per sec for root and 3.2mb per sec for the database file
system

Restore command is

ufsrestore rf /dev/rmt/0cbn

Recovery Tape Drive

mt -f /dev/rmt/0cbn status

HP Ultrium LTO 3 tape drive:
   sense key(0x6)= Unit Attention   residual= 0   retries= 0
   file no= 0   block no= 0

To me this looks like a 900% speed difference between the disk to tape
speed and the tape to disk speed and that does not seem right

Comments please as I need to reduce the recovery window if at all
possible

In article <1178172075.218699.247780@y80g2000hsf.googlegroups.com>,
	KiwiSpud <kiwispud@gmail.com> writes:
> Hi Guru's,
> 
> Can someone please tell me if this is normal or else give me clues as
> to what the possible problem is.
> 
> I have a v240 that is backing up to a HP LTO3 tape drive via its
> onboard scsi port and I am getting transfer rates of between 9.5mb per
> sec (for root) up to 27mb per sec for a database file system.
> 
> I then take that tape to another site with a v240 with equivalent cpu
> and memory config with a Sun badged HP LTO3 connected via its internal
> scsi card, boot from cdrom (latest sol 9hw) and get transfer rates of
> approx 1.2mb per sec for root and 3.2mb per sec for the database file
> system
> 
> Comments please as I need to reduce the recovery window if at all
> possible

The restore is going through the ufs filesystem, whereas the backup
is operating at the raw disk level.

You can speed up ufs for this sort of purpose by turning off logging
and turning on async writes. Search for "fastfs" command on the web.
This is a somewhat vulnerable state to leave a filesystem in, but
during a restore it doesn't much matter -- if the power fails halfway
through you can just newfs the corrupted filesystem and start the
restore again (assuming you're restoring a whole filesystem).

fastfs was hidden as one of the lu (live upgrade) commands, as lu
used it for exactly this purpose too, but I either can't find it or
can't recall what command name it hid under (which wasn't fastfs)
in Solaris 10.  You'll find it on the web though.

-- 
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

KiwiSpud wrote:
> Hi Guru's,
> 
> Can someone please tell me if this is normal or else give me clues as
> to what the possible problem is.
> 
> I have a v240 that is backing up to a HP LTO3 tape drive via its
> onboard scsi port and I am getting transfer rates of between 9.5mb per
> sec (for root) up to 27mb per sec for a database file system.
> 
> Backup Command is
> 
> /usr/sbin/ufsdump 0uf /dev/rmt/0cbn /
> 
> Backup Tape Drive
> 
> mt -f /dev/rmt/0cbn status
> 
> HP Ultrium LTO 3 tape drive:
>    sense key(0x0)= No Additional Sense   residual= 0   retries= 0
>    file no= 0   block no= 0
> 
> I then take that tape to another site with a v240 with equivalent cpu
> and memory config with a Sun badged HP LTO3 connected via its internal
> scsi card, boot from cdrom (latest sol 9hw) and get transfer rates of
> approx 1.2mb per sec for root and 3.2mb per sec for the database file
> system
> 
> Restore command is
> 
> ufsrestore rf /dev/rmt/0cbn
> 
> Recovery Tape Drive
> 
> mt -f /dev/rmt/0cbn status
> 
> HP Ultrium LTO 3 tape drive:
>    sense key(0x6)= Unit Attention   residual= 0   retries= 0
>    file no= 0   block no= 0
> 
> To me this looks like a 900% speed difference between the disk to tape
> speed and the tape to disk speed and that does not seem right
> 
> Comments please as I need to reduce the recovery window if at all
> possible
> 

That does not seem strange at all. It's quite different to write to a raw dev than 
to a UFS filesystem... Backup is easy, restore is hell.

KiwiSpud <kiwispud@gmail.com> writes:

>Can someone please tell me if this is normal or else give me clues as
>to what the possible problem is.

Possibly the disk and not the tape is the bottleneck.


Try ufsdump 0f /dev/null to get some sense of how fast the disk likes
to be backed up.


Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

KiwiSpud wrote:
> Hi Guru's,
> 
> Can someone please tell me if this is normal or else give me clues as
> to what the possible problem is.
> 
> I have a v240 that is backing up to a HP LTO3 tape drive via its
> onboard scsi port and I am getting transfer rates of between 9.5mb per
> sec (for root) up to 27mb per sec for a database file system.
> 
> Backup Command is
> 
> /usr/sbin/ufsdump 0uf /dev/rmt/0cbn /
> 
> Backup Tape Drive
> 
> mt -f /dev/rmt/0cbn status
> 
> HP Ultrium LTO 3 tape drive:
>    sense key(0x0)= No Additional Sense   residual= 0   retries= 0
>    file no= 0   block no= 0
> 
> I then take that tape to another site with a v240 with equivalent cpu
> and memory config with a Sun badged HP LTO3 connected via its internal
> scsi card, boot from cdrom (latest sol 9hw) and get transfer rates of
> approx 1.2mb per sec for root and 3.2mb per sec for the database file
> system
> 
> Restore command is
> 
> ufsrestore rf /dev/rmt/0cbn
> 
> Recovery Tape Drive
> 
> mt -f /dev/rmt/0cbn status
> 
> HP Ultrium LTO 3 tape drive:
>    sense key(0x6)= Unit Attention   residual= 0   retries= 0
>    file no= 0   block no= 0
> 
> To me this looks like a 900% speed difference between the disk to tape
> speed and the tape to disk speed and that does not seem right
> 
> Comments please as I need to reduce the recovery window if at all
> possible
> 

I've seen such behavior on another O/S (OpenVMS).  If it is possible to 
"pre-allocate" disk space for the file(s) being restored it might go a 
lot faster.  If the restore is doing something like looking for three 
free blocks on the disk, allocating those blocks, writing them and 
looping back for another three blocks, it's the bookkeeping that's 
killing you!

KiwiSpud wrote:
> Hi Guru's,
> 
> Can someone please tell me if this is normal or else give me clues as
> to what the possible problem is.
> 
> I have a v240 that is backing up to a HP LTO3 tape drive via its
> onboard scsi port and I am getting transfer rates of between 9.5mb per
> sec (for root) up to 27mb per sec for a database file system.
> 
> Backup Command is
> 
> /usr/sbin/ufsdump 0uf /dev/rmt/0cbn /
> 
> Backup Tape Drive
> 
> mt -f /dev/rmt/0cbn status
> 
> HP Ultrium LTO 3 tape drive:
>    sense key(0x0)= No Additional Sense   residual= 0   retries= 0
>    file no= 0   block no= 0
> 
> I then take that tape to another site with a v240 with equivalent cpu
> and memory config with a Sun badged HP LTO3 connected via its internal
> scsi card, boot from cdrom (latest sol 9hw) and get transfer rates of
> approx 1.2mb per sec for root and 3.2mb per sec for the database file
> system
> 
> Restore command is
> 
> ufsrestore rf /dev/rmt/0cbn
> 
> Recovery Tape Drive
> 
> mt -f /dev/rmt/0cbn status
> 
> HP Ultrium LTO 3 tape drive:
>    sense key(0x6)= Unit Attention   residual= 0   retries= 0
>    file no= 0   block no= 0
> 
> To me this looks like a 900% speed difference between the disk to tape
> speed and the tape to disk speed and that does not seem right
> 
> Comments please as I need to reduce the recovery window if at all
> possible
> 

just a guess: the tape is too fast for your disks to keep up and there
is no intermediate buffer. In consequence the tape has to stop, rewind a
little bit, which degrades performance dramatically.

Try using mbuffer (http://www.maier-komor.de/mbuffer.html) and give your
tape a buffer it can fill up at full speed. The buffer then can deliver
data to ufsrestore at any rate. Like this you will get much better
performance, because disk speed can vary from very slow to high speed
depending if a seek is necessary. Using mbuffer will also lengthen the
live of your tapedrive.

HTH,
Thomas

star will handle buffering and is faster than ufsdump/ufrestore.  Thats
a pretty fast tape drive so your disk subsystem may not be fast enough
to stream the tape.  If you have a raid disk array you can test with,
that may help get you better filesystem bandwidth.

Gregm

Greg Menke wrote:
> star will handle buffering and is faster than ufsdump/ufrestore.  Thats
> a pretty fast tape drive so your disk subsystem may not be fast enough
> to stream the tape.  If you have a raid disk array you can test with,
> that may help get you better filesystem bandwidth.
> 
> Gregm
> 

The buffering of star is very limited in contrast to the possibilities 
mbuffer offers. With mbuffer you can specify the buffer size, low/high 
water mark values, limit transfer rates to prevent network saturation 
with backups and more...

star is a really fine tool, but when it comes to buffering, I think 
mbuffer has more to offer.

- Thomas

In article <4639CD57.3080600@comcast.net>,
 "Richard B. Gilbert" <rgilbert88@comcast.net> wrote:

> KiwiSpud wrote:
> > Hi Guru's,
> > 
> > Can someone please tell me if this is normal or else give me clues as
> > to what the possible problem is.
> > 
> > I have a v240 that is backing up to a HP LTO3 tape drive via its
> > onboard scsi port and I am getting transfer rates of between 9.5mb per
> > sec (for root) up to 27mb per sec for a database file system.
> > 
> > Backup Command is
> > 
> > /usr/sbin/ufsdump 0uf /dev/rmt/0cbn /
> > 
> > Backup Tape Drive
> > 
> > mt -f /dev/rmt/0cbn status
> > 
> > HP Ultrium LTO 3 tape drive:
> >    sense key(0x0)= No Additional Sense   residual= 0   retries= 0
> >    file no= 0   block no= 0
> > 
> > I then take that tape to another site with a v240 with equivalent cpu
> > and memory config with a Sun badged HP LTO3 connected via its internal
> > scsi card, boot from cdrom (latest sol 9hw) and get transfer rates of
> > approx 1.2mb per sec for root and 3.2mb per sec for the database file
> > system
> > 
> > Restore command is
> > 
> > ufsrestore rf /dev/rmt/0cbn
> > 
> > Recovery Tape Drive
> > 
> > mt -f /dev/rmt/0cbn status
> > 
> > HP Ultrium LTO 3 tape drive:
> >    sense key(0x6)= Unit Attention   residual= 0   retries= 0
> >    file no= 0   block no= 0
> > 
> > To me this looks like a 900% speed difference between the disk to tape
> > speed and the tape to disk speed and that does not seem right
> > 
> > Comments please as I need to reduce the recovery window if at all
> > possible
> > 
> 
> I've seen such behavior on another O/S (OpenVMS).  If it is possible to 
> "pre-allocate" disk space for the file(s) being restored it might go a 
> lot faster.  If the restore is doing something like looking for three 
> free blocks on the disk, allocating those blocks, writing them and 
> looping back for another three blocks, it's the bookkeeping that's 
> killing you!

The rule of thumb I've always followed is backups run at least 3x the 
restore speed.  Any disaster recover plan should take this into account.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...

On May 3, 5:23 pm, and...@cucumber.demon.co.uk (Andrew Gabriel) wrote:
> In article <1178172075.218699.247...@y80g2000hsf.googlegroups.com>,
>         KiwiSpud <kiwis...@gmail.com> writes:
>
>
>
> > Hi Guru's,
>
> > Can someone please tell me if this is normal or else give me clues as
> > to what the possible problem is.
>
> > I have a v240 that is backing up to a HP LTO3 tape drive via its
> > onboard scsi port and I am getting transfer rates of between 9.5mb per
> > sec (for root) up to 27mb per sec for a database file system.
>
> > I then take that tape to another site with a v240 with equivalent cpu
> > and memory config with a Sun badged HP LTO3 connected via its internal
> > scsi card, boot from cdrom (latest sol 9hw) and get transfer rates of
> > approx 1.2mb per sec for root and 3.2mb per sec for the database file
> > system
>
> > Comments please as I need to reduce the recovery window if at all
> > possible
>
> The restore is going through the ufs filesystem, whereas the backup
> is operating at the raw disk level.
>
> You can speed up ufs for this sort of purpose by turning off logging
> and turning on async writes. Search for "fastfs" command on the web.
> This is a somewhat vulnerable state to leave a filesystem in, but
> during a restore it doesn't much matter -- if the power fails halfway
> through you can just newfs the corrupted filesystem and start the
> restore again (assuming you're restoring a whole filesystem).
>
> fastfs was hidden as one of the lu (live upgrade) commands, as lu
> used it for exactly this purpose too, but I either can't find it or
> can't recall what command name it hid under (which wasn't fastfs)
> in Solaris 10.  You'll find it on the web though.
>
> --
> Andrew Gabriel
> [email address is not usable -- followup in the newsgroup]

Hi, thanx for the replies, fastfs seems like the best option to me,
however I am not sure if it would be available since i am booting from
cdrom, could someone please clarify this for me

On May 4, 9:56 am, KiwiSpud <kiwis...@gmail.com> wrote:
> On May 3, 5:23 pm, and...@cucumber.demon.co.uk (Andrew Gabriel) wrote:
>
>
>
> > In article <1178172075.218699.247...@y80g2000hsf.googlegroups.com>,
> >         KiwiSpud <kiwis...@gmail.com> writes:
>
> > > Hi Guru's,
>
> > > Can someone please tell me if this is normal or else give me clues as
> > > to what the possible problem is.
>
> > > I have a v240 that is backing up to a HP LTO3 tape drive via its
> > > onboard scsi port and I am getting transfer rates of between 9.5mb per
> > > sec (for root) up to 27mb per sec for a database file system.
>
> > > I then take that tape to another site with a v240 with equivalent cpu
> > > and memory config with a Sun badged HP LTO3 connected via its internal
> > > scsi card, boot from cdrom (latest sol 9hw) and get transfer rates of
> > > approx 1.2mb per sec for root and 3.2mb per sec for the database file
> > > system
>
> > > Comments please as I need to reduce the recovery window if at all
> > > possible
>
> > The restore is going through the ufs filesystem, whereas the backup
> > is operating at the raw disk level.
>
> > You can speed up ufs for this sort of purpose by turning off logging
> > and turning on async writes. Search for "fastfs" command on the web.
> > This is a somewhat vulnerable state to leave a filesystem in, but
> > during a restore it doesn't much matter -- if the power fails halfway
> > through you can just newfs the corrupted filesystem and start the
> > restore again (assuming you're restoring a whole filesystem).
>
> > fastfs was hidden as one of the lu (live upgrade) commands, as lu
> > used it for exactly this purpose too, but I either can't find it or
> > can't recall what command name it hid under (which wasn't fastfs)
> > in Solaris 10.  You'll find it on the web though.
>
> > --
> > Andrew Gabriel
> > [email address is not usable -- followup in the newsgroup]
>
> Hi, thanx for the replies, fastfs seems like the best option to me,
> however I am not sure if it would be available since i am booting from
> cdrom, could someone please clarify this for me

nevermind, have searched cdrom and found it on cd0 in /s1/usr/sbin/
install.d

Thx for your help everyone, next up, test the restore again

Spud

In article <1178249929.466313.163340@h2g2000hsg.googlegroups.com>,
	KiwiSpud <kiwispud@gmail.com> writes:
> 
> nevermind, have searched cdrom and found it on cd0 in /s1/usr/sbin/
> install.d

Good catch -- I didn't know it was on the install disk.

-- 
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]