--CblX+4bnyfN0pR09
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* william.d.brown AT gsk DOT com <william.d.brown AT gsk DOT com> [2005-03-07 
16:27]:
>=20
> However a significant counter-argument, which many sites will find=20
> persuasive, is that the restore speed is also affected by the fragment=20
> size.  In the extreme case, that you don't have a fragment size set at=20
> all, there is just one fragment on a tape.  Any restore has to scan (at=
=20
> slow speed) the whole tape, reading it until the files required for=20
> restore are found.   With fragments, the tape can skip forward at high=20
> speed to the required fragment (it is just a record to the tape); it then=
=20
> has to read just that fragment at slow speed to get the files.  So unless=
=20
> you files are themselves >2GB, you would likely be happy with the 2GB=20
> fragment size.  It really depends on your data, and how often you do=20
> restores, how quick they have to be...vs some improved write speed.

We have ours set to 2G for exactly this reason. we often have very large
backups >500G with restore requests that would take forever without
giving NBU a hint where to look for it.

--=20
David Rock
david AT graniteweb DOT com

--CblX+4bnyfN0pR09
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCLKMIMrO4/Yb/xwYRAmdVAJ9b1jYU0QlrgXkCmN35xH72Xkrh6ACfdEWu
P1e9Xejpeq6wupmE66qxYLM=
=2wE6
-----END PGP SIGNATURE-----

--CblX+4bnyfN0pR09--