IBM Virtual Tape Appliance Research

Before we can suggest a solution with confidence, we need to know: Which LTO tape drive are you backing up to?   At least to know the generation: LTO-4, LTO-5, LTO-6, maybe earlier?, or IBM's model number.

Then: How much data are you backing up?  The solution may be very different if it's 1TB vs. 10 TB. vs. 100GB.   Knowing how much data will help us know your average backup performance.  How much of the nine hours is actual backup time (that is, are the tapes swapped promptly, or is there a significant wait time in between when a tape is full and the next one is available)?  Also helpful: Knowing how big the data is uncompressed, and how big it is compressed on the tape.

Knowing your average backup performance helps us understand where the bottleneck might be.  If you're only getting 30MB/sec to an LTO-3 or above, moving to a faster tape drive won't get your backups done any faster (save, perhaps, for not having to switch tapes in the middle) -- but neither will backing up to some kind of disk or VTL.   The low performance with a tape drive capable of writing much faster indicates that it's some other component which is the backup.  That bottleneck is very often the source disks.  It could be a mis-configured network or slow network (not so common now  that most are on GbE).  It could be processes like encryption or deduplication running on the backup server.

I can suggest that you check to make sure you are not compressing the data in software (that is, on the AS400 or backup server.  If so, turn that off and instead use "hardware compression", letting the tape drive do it without any performance penalty.

Likewise, if you are performing encryption on the backup server (or AS400), see if there is a solution that let's you use hardware encryption.  This is normally done through the backup software; I don't know how it would work in your environment.  Hardware encryption on LTO-4 or above tape drives has effectively no performance penalty (maybe 1% at most), as compared to a potential significant performance hit if using SW encryption.

Identifying the actual performance bottleneck before randomly buying more hardware is critical.  If you can only get 40MB/second off your disks, upgrading to a billionMB/sec tape drive won't help, because the disks can't get you more than 40MB/second.

Here is some more information for you:

System: Power 720
Tape Drive: LTO 4
Tapes: LTO4, 800/1600 GB
Running HMS/Medhost

We have been using the default GO SAVE, Option 21 - so I am unsure of the compression type used by default. We run through 2 tapes and part of a third. I am not personally experienced enough with the system to locate the default encryption type, and the report I run after the backup only tells me the number of objects saved - not the amount of data.

We have already contacted Medhost and they will be of ZERO assistance in altering the backup strategy.

Also, there is never more than 5 minutes between tapes being changed - just thought I should answer that inquiry as well.

GO SAVE, OPTION 21 defaults to DTACPR(*DEV) COMPACT(*DEV) SAVxxx options.  This tells the save commands to use native device compression or compaction if available, and if not, to perform no compression.

You don't mention your specific tape drive model, but I assume we're talking about a 3580 since you are talking about manually changing tapes.  3580 supports hardware data compaction - so that should be what is happening unless someone has modified command defaults or the save program.

If you already have LTO4 and if this AS/400 is the only system which uses the tape drive you certainly won't profit much from buying a VTL, let alone the value-for-money ratio.

Yes, based on the information provided on this thread our only value from a VTL would be not swapping tapes. So our only viable options would be a faster drive/tape scenario or devising a "save while active" strategy.

All you said in your last comment is  quite correct, indeed!

As our data changes very rapidly - we're a 24 hour orthopedic hospital  - I doubt that would be a solution. Accounts are worked on frequently, and not only are documents scanned in but forms are automatically generated and archived as PDFs - so there's a lot of changes every day.

TSM is a very fine product, we use it for more than 15 years now and I've become a big fan of it (better: an addict).

But in your environment there will be several heavy drawbacks, besides the fact that data change very rapidly:

- There is no TSM server version available for i5/OS, so you will have to purchase and install a new machine (AIX/Linux/Solaris/HPUX/Windows) to run the TSM server on. This machine must have sufficient power to run a DB/2 database (required by TSM) along with the basic TSM server code.

- A TSM server is not very easy to install and maintain. Most companies need external consulting/support people to do it, at least at the beginning.

- The TSM client for AS/400 is not as comprehensive as the client for other OSes. Basically it's an API interface between the native AS/400 BRMS and TSM. The BRMS application client to Tivoli Storage Manager requires "Backup Recovery and Media Services for iSeries", "OS/400 (i5/OS) Media Storage Extensions Feature" and "Tivoli Storage Manager Application Programming Interface for IBM i" (the API interface mentioned above). All this must be purchased by you.

- But now the biggest drawback: Only user data can be backed up to the Tivoli Storage Manager server. User data is any object that can be saved to a save file, but not "Licence Internal Code" (LIC), OS/400 (i5/OS) operating system, security data, configuration data, IBM supplied libraries and licensed programs.
System data can only be saved to local media and that's exactly the same as what you're doing now.

- In order to save user data the above mentioned new server must be equipped with sufficient storage media (disk/tape) which will have to be purchased in addition to the new TSM server hardware.

- TSM itself is not cheap (not at all!).

- In my previous comment I've been talking about the value-for money ratio of a VTL. I think you can imagine now that this ratio would be one to several orders of magnitude worse when talking about TSM in your environment.

To avoid misunderstandings: TSM is really fine for companies like ours with lots and lots of servers (no or only few AS/400s) and lots of terabytes of data to be saved. Once you have a well-performing server, a powerful tape library and sufficient space for backup-to-disk the life of a backup/recovery admin can become very easy.
Unfortunately all these critera do not seem to be met in your environment.

TSM is an option on AS/400, but using it as a tape device for BRMS (Backup and Recovery Media Services), another product from IBM, but specific of the AS/400.

Is the AS/400 a stand alone model? or is it virtualized on a chassis? because you can create VTL on a VIOS using SSD disk to make it fly, however this is only good if you don't have too much data to back up, otherwise SSD is rather expensive.

You can consider buying a somewhat cheap TS3100 with 2 LTO6 tape drives, and run 2 backup processes nightly with SWA *yes. I think that the most important thing you've got to do with your backup policy is to identify the LIBs that your application uses and do daily backups, weekly, and only once a month do a complete system save (go save, 21), because performing a full system save more often seems overkill, specially when taking that long.

Other option will be a second AS/400 BDU to save licensing costs with replication soft like iCluster, VISION, etc, that way you can backup from the STDBY system, without impacting users, and having your system protected by HA.

The as400 is standalone, with 1 tape drive. A two system setup for replication is not economically feasible for our facility, so right now our best option is to develop a save-while-active strategy to minimize downtime.