How to check the filesystem size few months back in hpux

[sanwin]

Hi,
Is there any way to find the filesystem size few months back in hpux.

Issue right now is the backup was taking 5 hrs before 5 months. now it is taking 10hrs.
The backup speed is same. But we were not able to find which is that filesystem which has increased that much as we don't have old filesystem size data.


could anyone help me regarding this.

thanks!!

regards,
sanwin

[Pete Randall]

To the best of my knowledge, there is no facility to accomplish this in HP-UX. What I do is email myself bdf output every day and save that in a folder once a month, giving me some historical perspective.


Pete

[SKR_1]

If you have kept the syslog.log backup, you can try to find out something relative.
Which utility you are using for backup, & what is the type of backup is?

Thanks

SKR

[Torsten.]

You may check the logs of your backup application, if you have ...

[Gokul Chandola]

Hi,
There is the concept of Defragmentation (option).
Please read docs for this.

Regards,
Gokul Chandola

[Sandeep_Chaudhary]

No way in HP-UX. U can check backup logs of 5 months back. There u get information

[Court Campbell]

As noted there is no default facility for this. For the future you may look at outputting bdf to a file on a weekly or monthly basis via cron. It never hurts to know your fs usage trends.

[john korterman]

Hi sanwin,

you could instead consult the logfiles of the backup system, as they could hold information concerning the amount af data transferred, speed, etc.
Then compare your findings with the changes to the OS system!

regards,
John K.

[Kapil Jha]

I think backup team would be having that information what was the file system size couple of months back.
How you taking backup netbackupp/tar or smthing else.

Thanks,
Kapil+

[OFC_EDM]

Is there and Openview agent installed on the server? If so post output of opcagt -status

From that we can tell if you have the full performance agent. The full performance agent will allow you to go back a few months in time and view filesystem information.

I also run a bdf daily. Instead of emailing it to myself I append it to a logfile on the system preceeded with a datestamp.

This log is archived regularly to keep it from growing too large.

[Duncan Edmonstone]

Kevin is correct, if you have a new enough version of the Performance Agent installed on this system then you might be able to pull metrics out on this. On my system I can do this:

mwa status

if that returns nothing you don't have the performance agents. Assuming you do then:

cat > /tmp/fsrept.cfg << EOF
DATA TYPE FILESYSTEM
DATE
TIME
FS_DIRNAME
FS_SPACE_USED
EOF

will create a report cfg file and then:

extract -xp -Y -r /tmp/fsrept.cfg -f /tmp/fsrept.out,Purge -b FIRST -e LAST

Will produce a report of filesystem usage. How far back it goes depends on your logs...

HTH

Duncan

[OFC_EDM]

Another tip

If you have the Openview Agent but NOT the full performance agent. The base agent still comes with a CODA performance agent...which is basically a subset of the Full performance agent...and does not store data historically. You may get the past week if lucky.

But you can run a command against it to pull data and then create your own data store.

Check out
/opt/OV/bin/codautil -dumpds
-support

You'd have to write scripts to extract what you need.

As well not all metrics can be taken at face value. Calculations would be needed within a script.

But many are useful.

Cheers

[Rita C Workman]

How far back does the history of your backups sessions go?

Since you know it used to take 5 hours and now it's 10 hours, why not look at your backup sessions and see if you can trace down when it started to increase significantly.
Then when you have a day try doing a search for files that appeared around that time and maybe sorting the output by largest file first.

Just a thought, but I agree with the earlier folks using OV.

Rita

[Bill Hassell]

The only way to separate the amount of data versus some other problem is to use the backup program to read the old tape(s) and calculate the amount of data that was backed up. Without this information, all reasons for a long er backup period will be guesses. Here are reasons for a changed backup period:

1. The data files are larger, and/or there are many more new files.

2. The data is becoming less compressible. If you run a database, the original datafiles were unpopulated and therefore highly compressible. After months of data gathering, the files will not be as compressible and therefore more tape will be required to hold the data (and more time).

3. The backup is occurring while the machine is busy, perhaps more so than in the past. Most modern tape drives cannot run at a slower speed and must therefore stop, backspace and re-record the slow block of data. This can easily double or triple the backup time. Modern tape drives require a minimum data rate which can be limited by CPU speed and usage as well as competing disk access from other processes.

Any one or a combination of these 3 conditions will increase the time to complete a backup.