Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
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
Community
Resources
Forums
Blogs
- 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-23-2003 05:39 AM
06-23-2003 05:39 AM
Tonight for the first time I will be using fbackup to run a full root system archive. Previously I have used tar but I now have files > 2Gb.
I am planning to use the command;
fbackup -f /dev/rmt/1m -i / -I /tmp/index.lucy
Will it work? I am testing now on one of my test servers but it's slow slow, I'm not sure whether or not it will finish in time!
Every night I also run an application specific backup so that is safe!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-23-2003 05:47 AM
06-23-2003 05:47 AM
SolutionIf you are not using a 'config' file with 'fbackup' you are going to get very poor backup performance.
As documented in the man pages for 'fbackup' in the absence of an explicit configuration file ('-c config'), default values are provided. However, these defaults are archaic and will not yield decent performance with modern tapes and tape drives. A much better set of parameters look something like these:
blocksperrecord 256
records 32
checkpointfreq 1024
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 200
filesperfsm 2000
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, FSM???s 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.
Regards!
...JRF...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-23-2003 05:47 AM
06-23-2003 05:47 AM
Re: fbackup
Normally you should supply fbackup with a config file (-c option) which helps backup times and restore times. Heres a typical one we use;
blocksperrecord 128
records 32
checkpointfreq 256
readerprocesses 4
maxretries 1
retrylimit 0
maxvoluses 500
Try using one like this, it should help your backup speed a fair bit.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-23-2003 05:50 AM
06-23-2003 05:50 AM
Re: fbackup
1. fbackup may kick out a lot of messages about files in use, because there will be files 'open' by root and other processes. This pretty much says that the file is not fully backed up.
2. How much data are you backing up hence, what type of tape drive/capacity are you backing up to? Fbackup will pause once the tape it is writing to is full.. To do a root system backup, I just do an Ignite of the system, which pretty much covers all of the critical system files that I need backed up.
Mike-
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-23-2003 05:52 AM
06-23-2003 05:52 AM
Re: fbackup
HTH,
Piyush
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-23-2003 05:58 AM
06-23-2003 05:58 AM
Re: fbackup
'fbackup' backup open files. When 'fbackup' begins to transfer a file from disk to tape, it notes the timestamp of the disk file. When the transfer of the disk image to tape completes, the timestamp is examined again. If it has changed, indicating a potential change in the file content, 'fbackup' will issue a warning message; mark the copy of the file on the tape as "bad" so that it cannot be recovered; and attempt to recopy the file. This recopy process will be attempted 'maxretries' times (as specified in the 'config' file for 'fbackup') or until the file can be successfully transferred to tape and remain unchanged on disk during the transfer.
One problem with the retry mechanism, as should be appparent from the above, is that time and tape are used. Thus retries can greatly slow down the overall backup time.
Regards!
...JRF...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-23-2003 06:10 AM
06-23-2003 06:10 AM
Re: fbackup
If you're making this backup in case you need to rebuild a system after failure then it would be far better to use make_tape_recovery. This makes recovery much easier than installing part of the OS, then having to use frecover the correct bits back again.
regards,
Darren.