Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE
Popy Absent Member.
Absent Member.
124 views

OmniBack-II, Performance

Jump to solution
Dear All,
I have a host with 35 filesystems, each having a size from 10 to 40 GB.While taking backup dataprotector is able to write all filesystems to the tape very fastly execept one 10 GB filesystem.
But for writing this particular filesystem omni session is taking around 1 hr.
All these filesystems are in same SAN.
I am using Dataprotector 5.1, XP-1024 Storage,ESL 6595 library,Host is a superdome 64 Way.
The only difference that I could trace between this 10Gb filesystem and others is the number of files are more.

Please help.

Regards
Raneesh Vijayan
0 Likes
1 Solution

Accepted Solutions
Highlighted
Contributor.. Bill Hassell Contributor..
Contributor..

Re: OmniBack-II, Performance

Jump to solution
Count the files and directories in the problem filesystem:

find /slow_filesystem | wc -l

If this filesystem has tens of thousands of files, you'll have high system overhead opening and closing files. sar -a 1 or Glance will confirm the high system overhead. The overhead may be just too much to keep the data flowing to te tape drive, which causes tape stop/restarts.


Bill Hassell, sysadmin
5 Replies
Highlighted
Contributor.. Bill Hassell Contributor..
Contributor..

Re: OmniBack-II, Performance

Jump to solution
Count the files and directories in the problem filesystem:

find /slow_filesystem | wc -l

If this filesystem has tens of thousands of files, you'll have high system overhead opening and closing files. sar -a 1 or Glance will confirm the high system overhead. The overhead may be just too much to keep the data flowing to te tape drive, which causes tape stop/restarts.


Bill Hassell, sysadmin
Leif Halvarsson Absent Member.
Absent Member.

Re: OmniBack-II, Performance

Jump to solution
Hi,

Yes, the number of files (or rather, the average filesize) has a big impact on backup performance. This has nothing to do with DP, the limitations is with the file/disk system. I don't know much about XP-1024 but, if there is any tuning paramerers you should try to maximize IOPS rather then througput.

A workaround, if your backup is mainly for distaster recovery (not frequently restoring single files), is to backup as a disk image.
0 Likes
Popy Absent Member.
Absent Member.

Re: OmniBack-II, Performance

Jump to solution
Thanks Bill, Leif,

Yes you are right, the number of files in that particular filesystem is very huge.(Around 12 Lacs).I appreciate both of you for your inputs.

Regards
Raneesh.Vijayan
0 Likes
Sandeep Kapare Absent Member.
Absent Member.

Re: OmniBack-II, Performance

Jump to solution
The performance of DP depends on the number of files & the size of files. If the number of files on a given file system is less but total size is big, as compared to large number of files but small total size, the backup of file system with hugh size will happen quickly. In our case, we are able to backup the database of 550 GB in 6 Hrs. In this case, the average file size is 3.5 GB. But on the other hand, one file system has more that 3 million files consuming only 700 MB space, & the backup goes on for almost 6 Hrs.
The backup process in this case has to open each file for reading, & then close it after backing-up.
The performance in your case can be improved by making multiple file systems, & placing (distributing) these files across these number of file systems.
Nothing is impossible
0 Likes
Jason Munson Absent Member.
Absent Member.

Re: OmniBack-II, Performance

Jump to solution
I have run into the exact situation you are in many times. There is another way to get around this, although there are limitations to this method as well. Using Data Protector 5.1, you can choose to back up this particular logical volume using the raw (disk image) method. A disadvantage is you will be backing up the entire volume, used as well as unused space. However, in every situation I do this it still saves time in orders of magnitude. You can back up the volume live (mounted/in use), but probably not recommended (like any backup). Therefore, if this is a database type filesystem and you do any sort of log switching or offline-backups, you'll need to take care of that in a pre-script before un-mounting the volume. We have developed ways to stop the application/database, split a copy/mirror off and mount them under a /splitmnt directory, then start the app/db back up, minimizing downtime.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.