- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- frecover taking days to retrieve a file
Operating System - HP-UX
1748223
Members
4634
Online
108759
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-29-2007 10:11 AM
тАО06-29-2007 10:11 AM
frecover taking days to retrieve a file
I have a frecover job that has now taken over 2 days (still running) to retrieve a file. The fbackup was made on a production system with a DLT7000 and is being frecover'ed on a DLT7000 on a test system. The tape contains about 5-10% small files and the rest are multi-Gigabyte ORACLE RMAN files, one of which I am trying to retrieve.
I have observed that the activity light quickly blinks about once per two seconds.
Does anyone have any ideas why it is taking soooooooo long?
Thanks,
Randy
I have observed that the activity light quickly blinks about once per two seconds.
Does anyone have any ideas why it is taking soooooooo long?
Thanks,
Randy
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-29-2007 11:34 AM
тАО06-29-2007 11:34 AM
Re: frecover taking days to retrieve a file
Hi Randy:
There are a couple of reasons that immediatly spring to mind.
If any of your files were changing during the time they were being copied, then 'fbackup' wrote more than one (up to 'maxretries' copies) onto the tape.
When 'fbackup' transfers a file from disk to tape it notes the checksum of the file. At the conclusion of the transfer, the checksum is computed again. If it differs, the copy of the file on the tape is marked "bad" so that it cannot be recovered later with 'frecover'. This retry mechanism consumes tape and proportionally lengthens both the backup and recovery time.
Backing up sparse files (very common in databases) without compression will cause a vast amount of media to be consumed (again, both at backup and at recovery time).
Unless you have modified the default parameters in the configuration file used with 'fbackup' you are probably going to see very poor performance. The manpages for 'fbackup(1M)' document the default settings which is what you will get in the *absence* of an explicily defined set.
Modern DLT tapes have different requirements than DDS ones. The 'fbackup' and 'frecover' manpages for 11.23 and/or 11.31 do a good job of discussing some of the configuration file changes they you can make.
These parameters are recorded onto the actual backup tape and are thus used for a 'frecover' session too.
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.
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.
It is also noteworthy that in some release after 11.31, 'fbackup' will be deprecated and new 'fbackup' archives will not be able to be created.
Regards!
...JRF...
There are a couple of reasons that immediatly spring to mind.
If any of your files were changing during the time they were being copied, then 'fbackup' wrote more than one (up to 'maxretries' copies) onto the tape.
When 'fbackup' transfers a file from disk to tape it notes the checksum of the file. At the conclusion of the transfer, the checksum is computed again. If it differs, the copy of the file on the tape is marked "bad" so that it cannot be recovered later with 'frecover'. This retry mechanism consumes tape and proportionally lengthens both the backup and recovery time.
Backing up sparse files (very common in databases) without compression will cause a vast amount of media to be consumed (again, both at backup and at recovery time).
Unless you have modified the default parameters in the configuration file used with 'fbackup' you are probably going to see very poor performance. The manpages for 'fbackup(1M)' document the default settings which is what you will get in the *absence* of an explicily defined set.
Modern DLT tapes have different requirements than DDS ones. The 'fbackup' and 'frecover' manpages for 11.23 and/or 11.31 do a good job of discussing some of the configuration file changes they you can make.
These parameters are recorded onto the actual backup tape and are thus used for a 'frecover' session too.
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.
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.
It is also noteworthy that in some release after 11.31, 'fbackup' will be deprecated and new 'fbackup' archives will not be able to be created.
Regards!
...JRF...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-29-2007 11:37 AM
тАО06-29-2007 11:37 AM
Re: frecover taking days to retrieve a file
hello randy.
What command are you using to retrieve the file ?
you can use a graph file to narrow down your recovery path
What command are you using to retrieve the file ?
you can use a graph file to narrow down your recovery path
Knowledge is power.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-29-2007 12:20 PM
тАО06-29-2007 12:20 PM
Re: frecover taking days to retrieve a file
Something is broken...frecover can position anywhere on the DLT within a few minutes. I would look at patches for fbackup/frecover and also for the latest tape drivers. Always use a config file with fbackup -- the defaults are designed for reel-to-reel drives.
Bill Hassell, sysadmin
Bill Hassell, sysadmin
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP