- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- make_tape_recovery problems
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
03-04-2003 06:51 AM
03-04-2003 06:51 AM
make_tape_recovery problems
My understanding is that the make_tape_recovery will create a list of all the filenames under /var/opt/ignite/recovery called flist. Once the flist is complete, it will "tar" those files and write to tape. What puzzles me is that we have another HP9000/B2000 workstation with the exact configuration and system resource. I ran make_tape_recovery only last week. The flist file only used about 5MB. We had about 140MB available under /var before the job kicked off. The job ran to its completion without any problem.
At first HP suggested that I upgrade to a newer version of Ignite-UX, which I did. But the problem continues.
Has anybody experienced similar problems? Your help will be greatly appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-04-2003 07:02 AM
03-04-2003 07:02 AM
Re: make_tape_recovery problems
which version of ignite are you using?
recent ignite release should solve this problem
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-04-2003 07:02 AM
03-04-2003 07:02 AM
Re: make_tape_recovery problems
What options are you using?
Regards
Victor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-04-2003 07:03 AM
03-04-2003 07:03 AM
Re: make_tape_recovery problems
Your '/var' free space is pitifully low. If you can't expand it, try regaining space by trimming log files like 'var/adm/wtmp' and '/var/adm/btmp', and running 'cleanup' this may gain you the space you need.
Since this is 10.20, run 'cleanup' without any arguments.
Regarde!
...JRF...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-04-2003 07:07 AM
03-04-2003 07:07 AM
Re: make_tape_recovery problems
Ignite-UX A.3.7.95 HP-UX System Installation Services
InstantIgnite B.10.20 Instant Ignition
And here is the command I used: #make_tape_recovery -a /dev/rmt/0mn -x inc_entire=vg00
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-04-2003 07:19 AM
03-04-2003 07:19 AM
Re: make_tape_recovery problems
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-04-2003 07:23 AM
03-04-2003 07:23 AM
Re: make_tape_recovery problems
Many machine operations will FAIL without adequate space on /var It stands for variable files, some of which can get quite large.
A quick way to clear space is.
sam
routine tasks
System Log Files
It can trim those logs and clear space.
Current Ignite for 11.11 is 4.1.62
Make sure you don't hae the latest pax patch in, or you won't be able to use the tapes.
PHCO_26422 Is a big no no here.
SEP
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-04-2003 07:27 AM
03-04-2003 07:27 AM
Re: make_tape_recovery problems
make_tape_recovery -Av
There you should see whats going on, no?
All the best
Victor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-04-2003 07:34 AM
03-04-2003 07:34 AM
Re: make_tape_recovery problems
1) Before you install the ignite software, apply the latest patches to the system including pax(1) patch.
2) Run make_tape_recovery with -v (verbose) and see what actually happens during the process.
3) What's the total /var space? if it's very high and if the free space is very small compared to the total space, then 'bdf' will report the file system as 100%.
4) Check the file system space with du command before and after the command execution. See which directory is getting full.
5) You might need to think about increasing space on /var.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-05-2003 03:23 AM
03-05-2003 03:23 AM
Re: make_tape_recovery problems
to me it looks like you have a problem with the "Boot Destination File". By default this is /var/tmp/uxinstlf.recovery.
Try the -B option to point this to a different file system where you have more space (you only need it temporarily, that's why it should go into /var/tmp actually).
After you start make_tape_recovery watch this file which you specified with -B.
Regards,
Bernhard