<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: fbackup delay long time in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/fbackup-delay-long-time/m-p/3864900#M277334</link>
    <description>Hi Isaac:&lt;BR /&gt;&lt;BR /&gt;Two thing immediately come to mind.&lt;BR /&gt;&lt;BR /&gt;First, 'fbackup' is designed to work while files are inuse. 'fbackup' attempts to insure a good copy of a file is placed on tape by comparing the timestamp of the file at the end of the copy to the timestamp of the file seen at the beginning of the transfer. If these do not match, 'fbackup' marks the file as "bad" and retries the copy. The retry ('maxretries') default is five (5) and can be defined in the 'config' file associated with 'fbackup'.  Thus, if you have files that are changing as you attempt to back them up, you will spend considerable time retrying their copy whether or not that copy is ultimately successful.&lt;BR /&gt;&lt;BR /&gt;Second, be sure to specify your own configuration file for 'fbackup'. The default values that you will otherwise obtain are out-dated and will generally give very poor performance during backup and recovery. Build a configuration file that looks like:&lt;BR /&gt;&lt;BR /&gt;blocksperrecord 4096&lt;BR /&gt;records 64&lt;BR /&gt;checkpointfreq 4096&lt;BR /&gt;readerprocesses 6&lt;BR /&gt;maxretries 5&lt;BR /&gt;retrylimit 5000000&lt;BR /&gt;maxvoluses 200&lt;BR /&gt;filesperfsm 2000&lt;BR /&gt;&lt;BR /&gt;The manpages for 'fbackup(1M)' document the default settings which is what you will get in the *absence* of an explicily defined set.&lt;BR /&gt;&lt;BR /&gt;These parameters are recorded onto the actual backup tape and are thus used for a 'frecover' session too. &lt;BR /&gt;&lt;BR /&gt;Checkpoint records allow the salvage of a backup when a bad tape spot is detected, since the records contain information about the file being backed up. The 'filesperfsm' parameter controls the frequency with which Fast Search Marks (FSM) are written. Both checkpoint and FSM records affect performance. FSMs take a tape drive out of streaming mode thereby adding to backup time. Conversely, however, FSMs improve the time it take to recover a file from tape. &lt;BR /&gt;&lt;BR /&gt;In general, if your backup consists of a high proportion of small files, increase the value for 'filesperfsm'. If your backup consists of a high proportion of large files, then decrease the 'filesperfsm' value. &lt;BR /&gt;&lt;BR /&gt;Regards!&lt;BR /&gt;&lt;BR /&gt;...JRF...</description>
    <pubDate>Mon, 18 Sep 2006 15:41:13 GMT</pubDate>
    <dc:creator>James R. Ferguson</dc:creator>
    <dc:date>2006-09-18T15:41:13Z</dc:date>
    <item>
      <title>fbackup delay long time</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/fbackup-delay-long-time/m-p/3864898#M277332</link>
      <description>Hi: I have a problem when use Fbackup command to made a full backup system, following is the sintax that use for them :&lt;BR /&gt;(with fbackup the process, stay in spleep mode and delay arrow 14 hours, when in the past delay arround 2 hours, and we have the same quatity of data. We change the DDS3 to discart a hardware problem. We have other Drive but is the same error with it)&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;fbackup -f /dev/rmt/0m -i / -I /tmp/backuplist.txt&lt;BR /&gt;&lt;BR /&gt;I use other utilites for backup like tar, cpio and ignite and all of work fine and fast.&lt;BR /&gt;&lt;BR /&gt;Some one have a Idea ?&lt;BR /&gt;&lt;BR /&gt;Thank a lot &lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Mon, 18 Sep 2006 15:27:15 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/fbackup-delay-long-time/m-p/3864898#M277332</guid>
      <dc:creator>Isaac_4</dc:creator>
      <dc:date>2006-09-18T15:27:15Z</dc:date>
    </item>
    <item>
      <title>Re: fbackup delay long time</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/fbackup-delay-long-time/m-p/3864899#M277333</link>
      <description>Do you have any NFS mount points? &lt;BR /&gt;Check  syslog for any errors. &lt;BR /&gt;&lt;BR /&gt;run fbackup to backup like some directory size of 4GB and see how much time it takes to complete?&lt;BR /&gt;&lt;BR /&gt;Also check size of fbackup binary file.&lt;BR /&gt;&lt;BR /&gt;-r-xr-xr-x   1 bin        bin          77824 Apr 17  2003 /usr/sbin/fbackup&lt;BR /&gt;</description>
      <pubDate>Mon, 18 Sep 2006 15:33:20 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/fbackup-delay-long-time/m-p/3864899#M277333</guid>
      <dc:creator>IT_2007</dc:creator>
      <dc:date>2006-09-18T15:33:20Z</dc:date>
    </item>
    <item>
      <title>Re: fbackup delay long time</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/fbackup-delay-long-time/m-p/3864900#M277334</link>
      <description>Hi Isaac:&lt;BR /&gt;&lt;BR /&gt;Two thing immediately come to mind.&lt;BR /&gt;&lt;BR /&gt;First, 'fbackup' is designed to work while files are inuse. 'fbackup' attempts to insure a good copy of a file is placed on tape by comparing the timestamp of the file at the end of the copy to the timestamp of the file seen at the beginning of the transfer. If these do not match, 'fbackup' marks the file as "bad" and retries the copy. The retry ('maxretries') default is five (5) and can be defined in the 'config' file associated with 'fbackup'.  Thus, if you have files that are changing as you attempt to back them up, you will spend considerable time retrying their copy whether or not that copy is ultimately successful.&lt;BR /&gt;&lt;BR /&gt;Second, be sure to specify your own configuration file for 'fbackup'. The default values that you will otherwise obtain are out-dated and will generally give very poor performance during backup and recovery. Build a configuration file that looks like:&lt;BR /&gt;&lt;BR /&gt;blocksperrecord 4096&lt;BR /&gt;records 64&lt;BR /&gt;checkpointfreq 4096&lt;BR /&gt;readerprocesses 6&lt;BR /&gt;maxretries 5&lt;BR /&gt;retrylimit 5000000&lt;BR /&gt;maxvoluses 200&lt;BR /&gt;filesperfsm 2000&lt;BR /&gt;&lt;BR /&gt;The manpages for 'fbackup(1M)' document the default settings which is what you will get in the *absence* of an explicily defined set.&lt;BR /&gt;&lt;BR /&gt;These parameters are recorded onto the actual backup tape and are thus used for a 'frecover' session too. &lt;BR /&gt;&lt;BR /&gt;Checkpoint records allow the salvage of a backup when a bad tape spot is detected, since the records contain information about the file being backed up. The 'filesperfsm' parameter controls the frequency with which Fast Search Marks (FSM) are written. Both checkpoint and FSM records affect performance. FSMs take a tape drive out of streaming mode thereby adding to backup time. Conversely, however, FSMs improve the time it take to recover a file from tape. &lt;BR /&gt;&lt;BR /&gt;In general, if your backup consists of a high proportion of small files, increase the value for 'filesperfsm'. If your backup consists of a high proportion of large files, then decrease the 'filesperfsm' value. &lt;BR /&gt;&lt;BR /&gt;Regards!&lt;BR /&gt;&lt;BR /&gt;...JRF...</description>
      <pubDate>Mon, 18 Sep 2006 15:41:13 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/fbackup-delay-long-time/m-p/3864900#M277334</guid>
      <dc:creator>James R. Ferguson</dc:creator>
      <dc:date>2006-09-18T15:41:13Z</dc:date>
    </item>
    <item>
      <title>Re: fbackup delay long time</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/fbackup-delay-long-time/m-p/3864901#M277335</link>
      <description>Are you backing up a *large* number of files *and* you have almost no RAM installed (ie, less than 1000 megs)? Then the answer id=s that this is perfectly normal. fbackup does not simply copy files to tape like tar. Instead, it starts by finding every file you asked for and storing information about the file into shared memory. For a very small system, it will take between 60 and 100 megs to hold all these file and directory names. For tens of thousands of files, you'll need as much as 200 to 400 megs of shared memory. Once the files have been found, a complete index is created on the tape by reading this shared memory area, then at least 4 and up to 6 copies of the file-reader program are started to keep the tape busy.&lt;BR /&gt; &lt;BR /&gt;If you do not have enough RAM, the HP-UX will keep running by using swap space. While this is a very nice feature (to run a lot more memory than actually installed), your system will be massively paging (swapping) so performance will be awful. Add a couple of gigabytes of RAM and try again.</description>
      <pubDate>Mon, 18 Sep 2006 22:26:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/fbackup-delay-long-time/m-p/3864901#M277335</guid>
      <dc:creator>Bill Hassell</dc:creator>
      <dc:date>2006-09-18T22:26:38Z</dc:date>
    </item>
  </channel>
</rss>

