vgmount on multiple servers

[Gary Glick]

Here's whats going on:
I have Openmail running on a D-class server.
I have a rather large data volume (200GB+)
The data volume is on a VA7410 SAN.
I need to back this up.
I am using data protector.

The 100 MB NIC that I have in the D-class is too slow to run the backups over.

I was thinking about mounting the data store on another server with a Gig card in RO mode to run the backup on. It seems that this is frowned upon. Is this correct or would it be ok? Any other suggestions. I do not have business copy and money is tight and not likely to be approved, though I am checking on that route too. I am, most likely, not going to be able to switch the openmail volume to RO for the duration of the backup.

I do have mirror/ux on the server which is running 11.0

Any thoughts ideas or suggestions would be appreciated.

Thank you

Gary

[Bill Hassell]

The problem is with the server. The D-class was an excellent server back in the 90's but with the volume of data you have, you have no choice but to attach a local tape drive. Network cards should always be looked at as a very small pipe which requires a lot of CPU cycles to keep busy. 100Mbit LAN is barely able to keep slower tape drives busy, but using NFS (exporting the filesystem) makes things a *lot* worse. NFS is a complex protocol designed for managing files and directories, not stream data into a tape drive.

Basically, your data has exceeded the original system design. It probably works well as an OpenMail server but as is typical with email systems without serious quotas on email storage, the data is now too big to backup over a network. A 6-tape DDS autoloader may be a good solution or a DLT library, either one connected directly to the D-class. If you have no choice but to use a network backup, then you'll have to switch servers. Putting a Gig card will increase the data rate but not the packet rate. The packets require CPU time which introduce delays, so you won't get anywhere near a 10x improvement in speed.

[A. Clay Stephenson]

Your attempt to mount the volumes read-only will almost work perfectly --- the very worst kind of problem. I assume that Openmail uses cooked files (ie those housed in a filesystem). Your fundamental problem is that even mounted read-only there is a buffer cache consistancy problem. With one host running read-write the other host doesn't have a clue about what's happening to the other host's buffer cache. At best, your will get dirty reads occasionally. This would be far from a reliable backup. A better plan (assuming this is a vxfs filesystem and that you have onlineJFS) would be to very briefly shutdown, make a vxfs snapshot mount, and restart Openmail. You then backup the snapshot and you really don't care how long it takes because your users are up and running. Vxfs snapshots even of very large filesystems take only seconds because you really aren't copying data. The snapshot is comprised of unaltered blocks in the original filesystem plus copies which are written to a snapshot buffer just before a write occurs in the orignal filesystem. When the backup is complete, you unmount the snapshot and you are ready for the cycle to repeat.
You now don't need any business copy.

[Gary Glick]

Yeah I know that the system is being pushed well past its original design limits, and we are working to get it retired completely. but in the meantime, i've still got the backup problem. I had a lot of problems with the 6 tape auto changers.

Clay, how does one make a snapshot mount of the file system? I do have OnlineJFS on this system.

Gary

[Gary Glick]

I forgot to mention that I also have Mirror/UX on this system. if that could be of use.

[A. Clay Stephenson]

Snapshot mounts are very easy. You need a snapshot buffer device (a block device, either a whole disk or an LVOL) that is typically about 15% the size of the original filesystem. 15% is generous for reasonably active filesystems with backups limited to ~ 10 hours or so.

Let's suppose that your original vxfs filesystem is mounted as /fs1. Your newly created snapshot buffer is /dev/vg05/lvol1 and we will mount your snapshot as /snapfs1.

1) Shutdown Openmail
mkdir -p -m 755 /snapfs1
mount -F vxfs -o snapof=/fs1 /dev/vg05/lvol1 /snapfs1
2) Startup Openmail
3) Backup /snapfs1
4) umount /snapfs1
rmdir /snapfs1

Man mount_vxfs for details.

[Peyman Javaheri]

Hi Gary,

I am using snapshots, but I don't think you can mount snapshots across systems.

Have you thought about application level mirror copies? I mean apps like rsync, which allows having a mirror copy of a directory structure across systems. The nice feature of rsync is that it only copies the difference of files after a full copy, so traffic will be insignificant. However, it is a file copy and if you application has a database it might not work correctly.

Another more expensive option would be SAN with F/C tape libraries. This way you can share your tape drives among systems and backup through SAN rather than network.

Regards,
Peyman;

[Gary Glick]

I'm not familiar with rsync, I'll look into it. Open mail uses a lot of little files rather than one large one, so this might be an option.

The data volume I'm needing to back up is on a VA7410 and if I could back it up straight form there to DAtaprotector (Windows Version), that would be great.

[Peyman Javaheri]

If files don't change very often rsync might be a viable option over network (but slow). You can set it up to sync over NFS, SMB, ssh (slower), or rsync daemon itself.

for future planning......In our SAN environment, I have all the servers share the tape libraries, so we can backup from any server directly to the tape drive through SAN, which prevents data to go over network (LAN-free backup). This configuration helps us maintain minimal number of tape drives (4) for lots of data (terabytes) by scheduling backups through Data Protector (look in Data protector Admin Guide: â Shared Devices in the SAN Environmentâ ).

re