<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Kommentare zu: Backup Teil 1 &#8211; Backup to Disk</title>
	<atom:link href="http://otmanix.de/2008/06/14/backup-teil1-backup-to-disk/feed/" rel="self" type="application/rss+xml" />
	<link>http://otmanix.de/2008/06/14/backup-teil1-backup-to-disk/</link>
	<description>Wissenswertes und Belangloses aus dem Leben eines Admins</description>
	<lastBuildDate>Wed, 08 Feb 2012 17:04:26 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>Von: Filip Westers</title>
		<link>http://otmanix.de/2008/06/14/backup-teil1-backup-to-disk/#comment-699</link>
		<dc:creator>Filip Westers</dc:creator>
		<pubDate>Tue, 05 Aug 2008 13:06:05 +0000</pubDate>
		<guid isPermaLink="false">http://otmanix.de/?p=565#comment-699</guid>
		<description>Hi, thanks for your info, we have already tried a few of those. Performance tape to tape in our old Networker environment is between 100-120 MB/s, same for reading from tape, which is almost twice as fast as in our new environment. We are going to test Networker 7.4.2 on Sol 10, V240, SL500, LTO3, FLX_210 with UFS to see what the performance is and after that with ZFS. Will keep you posted abt. outcome.</description>
		<content:encoded><![CDATA[<p>Hi, thanks for your info, we have already tried a few of those. Performance tape to tape in our old Networker environment is between 100-120 MB/s, same for reading from tape, which is almost twice as fast as in our new environment. We are going to test Networker 7.4.2 on Sol 10, V240, SL500, LTO3, FLX_210 with UFS to see what the performance is and after that with ZFS. Will keep you posted abt. outcome.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: otmanix</title>
		<link>http://otmanix.de/2008/06/14/backup-teil1-backup-to-disk/#comment-698</link>
		<dc:creator>otmanix</dc:creator>
		<pubDate>Thu, 31 Jul 2008 18:51:41 +0000</pubDate>
		<guid isPermaLink="false">http://otmanix.de/?p=565#comment-698</guid>
		<description>Hi Filip, me again ;)
Have a look at: 
http://www.sun.com/bigadmin/content/submitted/tapedrive_perftuning.jsp
Also read esg68367, esg53349 and esg57225 in EMC knowledgebase on https://powerlink.emc.com

Here you find sth like this:
...
Starting with 6.0, there are a bunch of new environment variables that can be used to control this sort of behavior:
In addition to the available NSR_DEV_BLOCK_SIZE_xxx, there are now:
NSR_DEV_TAPE_FILE_SIZE_xxx
NSR_DEV_DEFAULT_CAPACITY_xxx
NSR_DEV_LOAD_TIME_xxx
NSR_DEV_LOAD_POLL_INTERVAL_xxx
NSR_DEV_LOAD_TRY_LIMIT_xxx
The default value for the Ultrium is 64k blocks and 16384 blocks between filemarks. To increase the tape file size, try this environment variable:
NSR_DEV_TAPE_FILE_SIZE_LTO_ULTRIUM=nnn
Where nnn is a number greater than 32 and less than 2^64 - 1 (i.e. a real, real big value). A good value to try would be something like 200000 (two hundred thousand). This should decrease the filemarks to about one every 10 to 15 minutes. In general, try to set devices up to write filemarks as often as possible without affecting write performance &quot;too much&quot;. Usually try to keep the impact to under 1% (More filemarks means better tape locating performance during recovers.) 
...</description>
		<content:encoded><![CDATA[<p>Hi Filip, me again <img src='http://otmanix.de/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /><br />
Have a look at:<br />
<a href="http://www.sun.com/bigadmin/content/submitted/tapedrive_perftuning.jsp" rel="nofollow"></a><a href='http://www.sun.com/bigadmin/content/submitted/tapedrive_perftuning.jsp'>http://www.sun.com/bigadmin/content/submitted/tapedrive_perftuning.jsp</a><br />
Also read esg68367, esg53349 and esg57225 in EMC knowledgebase on <a href="https://powerlink.emc.com" rel="nofollow"></a><a href='https://powerlink.emc.com'>https://powerlink.emc.com</a></p>
<p>Here you find sth like this:<br />
&#8230;<br />
Starting with 6.0, there are a bunch of new environment variables that can be used to control this sort of behavior:<br />
In addition to the available NSR_DEV_BLOCK_SIZE_xxx, there are now:<br />
NSR_DEV_TAPE_FILE_SIZE_xxx<br />
NSR_DEV_DEFAULT_CAPACITY_xxx<br />
NSR_DEV_LOAD_TIME_xxx<br />
NSR_DEV_LOAD_POLL_INTERVAL_xxx<br />
NSR_DEV_LOAD_TRY_LIMIT_xxx<br />
The default value for the Ultrium is 64k blocks and 16384 blocks between filemarks. To increase the tape file size, try this environment variable:<br />
NSR_DEV_TAPE_FILE_SIZE_LTO_ULTRIUM=nnn<br />
Where nnn is a number greater than 32 and less than 2^64 &#8211; 1 (i.e. a real, real big value). A good value to try would be something like 200000 (two hundred thousand). This should decrease the filemarks to about one every 10 to 15 minutes. In general, try to set devices up to write filemarks as often as possible without affecting write performance &#8220;too much&#8221;. Usually try to keep the impact to under 1% (More filemarks means better tape locating performance during recovers.)<br />
&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: otmanix</title>
		<link>http://otmanix.de/2008/06/14/backup-teil1-backup-to-disk/#comment-697</link>
		<dc:creator>otmanix</dc:creator>
		<pubDate>Thu, 31 Jul 2008 18:00:40 +0000</pubDate>
		<guid isPermaLink="false">http://otmanix.de/?p=565#comment-697</guid>
		<description>Hi Filip, 
I don&#039;t do tape to tape clones at the moment so I can&#039;t give you that performance value. Disk to tape staging or backup to tape is about the the same speed as you mentioned. I can&#039;t compare the performance to our old environment with LTO2 and Solaris9 on a V480. Here we had an extreme bottleneck in network performance. We changed to link aggregation on Solaris10 with more nic ports which boosted the overall throughput. We will change to storage-internal B2D (with EMC Timefinder/EMC Replication Manager) for our mission critical databases next year.</description>
		<content:encoded><![CDATA[<p>Hi Filip,<br />
I don&#8217;t do tape to tape clones at the moment so I can&#8217;t give you that performance value. Disk to tape staging or backup to tape is about the the same speed as you mentioned. I can&#8217;t compare the performance to our old environment with LTO2 and Solaris9 on a V480. Here we had an extreme bottleneck in network performance. We changed to link aggregation on Solaris10 with more nic ports which boosted the overall throughput. We will change to storage-internal B2D (with EMC Timefinder/EMC Replication Manager) for our mission critical databases next year.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Filip Westers</title>
		<link>http://otmanix.de/2008/06/14/backup-teil1-backup-to-disk/#comment-696</link>
		<dc:creator>Filip Westers</dc:creator>
		<pubDate>Thu, 31 Jul 2008 15:57:57 +0000</pubDate>
		<guid isPermaLink="false">http://otmanix.de/?p=565#comment-696</guid>
		<description>Hi, how is the cloning and/or reading performance from tape to tape in your environment. Our environment comprises of Solaris 10, T2000 sun cluster, SL8500, LTO3 and Networker 7.4.2 and we have serious issues with cloning performance as it does not come above 65 MB/s and it seems related to the reading speed as this also does not come above the 65MB/s which is way slower than we get with our old environment, Sol 9, 2x V440, SL8500, LTO3, Networker 7.2.2.</description>
		<content:encoded><![CDATA[<p>Hi, how is the cloning and/or reading performance from tape to tape in your environment. Our environment comprises of Solaris 10, T2000 sun cluster, SL8500, LTO3 and Networker 7.4.2 and we have serious issues with cloning performance as it does not come above 65 MB/s and it seems related to the reading speed as this also does not come above the 65MB/s which is way slower than we get with our old environment, Sol 9, 2x V440, SL8500, LTO3, Networker 7.2.2.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

