Using the OSVault GUI To Recycle Tapes

In release 5.0.38 of the OSVault GUI, a button was added to automate the un-migration of files from a tape volume, as shown in the example below.  In conjunction with the Media Usage report, you can use this screen to move all files off a tape that is not very full so that the tape can be removed from the library or recycled.

When you go to the Media screen, and click on a tape volume, the above window will appear.  You should then click the "Display Current Tape Contents" to see what files are on the tape and get a count of files on the tape.  If that tape is mostly empty, you can then click the "Unmigrate Volume" button, which will start the process to make sure that all files on the tape are restored back to disk and marked as not-resident on any tape volume.

When the Unmigrate window opens, you must then confirm that you want to unmigrate that tape by again clicking on the button with the tape volume displayed.  That will then start the process of finding all files in /cache that are copied (or only resident) on the selected tape volume.  Once all files are identified, a work queue is built of those files and the restore of files only on tape is started back to disk storage.   This process will take some time to complete.  The window will display the progress.

When the unmigrate is complete, you should repeat the above process to insure that all files are marked as not present on the select tape volume.

Technical Details on LTFS Implementation with OSVault

For the past two years, we have been working on getting LTFS support into OSVault.  That work is complete and this posting is an attempt to outline the technical details in that development effort.

For those who may not be familiar with LTFS,  you can read a writeup about it at Wikipedia.org.  The import thing to note is that LTFS requires LTO-5 or LTO-6 tape drives.  LTFS cannot work on LTO-4 or earlier tape models.  Also, converting an existing OSVault TAR-based tape system to LTFS is not an easy task and is not outlined in this posting.

Our implementation of LTFS support in OSVault allows for files to be stored in the XFS file system on spinning disk, and to have those files stored in that file system automatically be copied to a tape in the LTFS format.  When the XFS file system is becoming full, the data portion of older files is truncated from the XFS file system for those files that have been copied to LTFS tape.  If a truncated file is opened later, OSVault uses the DMAPI interface to realize this and will automatically restore the file to spinning disk from the tape cartridge before the first I/O on the file is allowed to proceed.

There are five major steps in getting LTFS support into OSVault:

1. The LTFS file system support had to be installed in the LINUX system that OSVault runs under
2. The AUTOFS implemenation for SCSI medium changers (tape libraries) had to be developed that supported LTFS mounts and unmount
3. The LIN_TAPE device driver had to be ported to the DMAPI kernel
4. The Migration (copying) program had to be modified to support LTFS
5. A LTFS_INV program to label all media in a robotic tape library and to update the database with that information

LTFS File System

Getting the LTFS file system was the easiest part of the implementation, since we used IBM's LTFS packages. Currently we are using LTFS 1.3.0 and that software is installed using an IBM-provided RPM package for CentOS 5.8.
Using the standard IBM package gives us several advantages beyond labor savings in the development process.  The biggest is that this baseline is the first implemenation of LTFS and has the most test time in its implementation (since 2010).  On interchangeability of our tapes to other LTFS system, we can be reasonably sure that any difficulties are due to the other product, since we are using an industry-standard implementation and have not made any modifications for our product.

AUTOFS Implementation

This was probably the most difficult part of the LTFS development.  We have been using AUTOFS 4.1.2 historically for mounting and unmounting DVD and Blu-Ray media in OSVault.  Tape (TAR) support in OSVault did not use AUTOFS.  However, due to the nature of LTFS, it was determined that the best way to support LTFS in OSVault was to use AUTOFS (and the automount daemon) to mount and dismount tape media.
The AUTOFS allows the LINUX system to show every tape in the tape library as a separate folder in the /archive mount point.  So, if tapes in the library have barcodes of OS0901L5, OS0902L5, OS0903L5, OS0904L5, and OS0905L5, then the folders /archive/OS0901L5, /archive/OS0902L5, /archive/OS0903L5, /archive/OS0904L5, and /archive/OS0905L5 are available to write to and read from.
In the above example, even though there are 5 tapes in the library, you can randomly access folders even if you have as few as one LTO-5 drive (although we recommend at least 3 drives in a production environment).  The AUTOFS implementation will remove/unmount media to put requested media into a drive without the user needing to worry about that.
The AUTOFS changes included the creation of a new automounter module, mount_ltfs and lookup_ltfs.  Those two modules deal with the robotic operations of moving media into and out of tape drives, finding the correct media in the robotic library, verifying that the tape in the drive has the same internal label as the barcode on the outside, and figuring out which tape drive to use for various operations.
A custom change to AUTOFS was to add in code to do an LTFS-specific set of operations when the tape drive mount times-out, as from inactivity.  In most AUTOFS modules, there is only a generic umount done on the folder when it times out from inactivity.  In our LTFS support, it is necessary to issue an unload to the tape drive, to take the media off the recording heads and return the tape into the cartridge (a generally accepted practice when not using a tape drive).
One of the advantages of using AUTOFS for LTFS access is that it is possible for networked users to directly read from the tape media, bypassing the /cache file system in OSVault.

LIN_TAPE Driver Port to DMAPI Kernel

We use the DMAPI interface to control the automatic restore of file data from removable media back to the XFS file system on spinning disk.  The DMAPI code is not in the mainline LINUX kernel, and OSStorage has had to maintain their own baseline of kernel patches.  We started with the 2.6.24-rc3 baseline that had DMAPI included in the XFS file system many years ago, and have been adding patches to that kernel to keep up with new devices and other kernel changes over the years.
Adding the LIN_TAPE driver (IBM's standard open-source driver for LTO tape drives) to this kernel was challenging.  LIN_TAPE had many conditionals in the source code based on the 2.6.24 release, which our kernel reported as supporting.  But since we had a Release Candidate, some of the SCSI interfaces had changed and our LIN_TAPE port did not match up correctly.  So the LINUX SCSI Interface code in LIN_TAPE had to be modified to match our kernel's implementation.

Migration to LTFS

OSVault transparently restores files from LTFS to the XFS file system when requested.  But prior to that restore, the file had to be copied to tape media.  We decided to modify the migration code that supports writing to BD-RE media (Blu-Ray rewritable media) and apply that the LTFS.  Not many changes were required and this migration code has been extensively used in our lab and at customer sites since as early as 2003.  The major changes required adding and "ltfs" format to the MySQL database and changing the database calls to support LTFS media entries.  Since BD-RE media only goes to 100GBytes, a lot of subsequent testing was required to make sure that this migration program would continue to work up to 2.5TBytes of storage per media.

LTFS_INV Program

A tape inventory program had to be developed that could query a SCSI Medium Changer (Robotic tape library) and create a database of tape media found in that tape library.  That "ltfs_inv" program has been tested on Qualstar and SpectraLogic brands of tape libraries, but should work on any tape library that supports the SCSI standard for Medium Changers and has LTO-5 or LTO-6 tape drives.
The ltfs_inv program loads all tapes in the library into tape drives, checks if it already has an LTFS file system on it, and if not it will format the tape with the LTFS file system. The internal volume label of the LTFS file system is also set to match the barcode on the outside of the tape cartridge and that internal volume label is checked each time OSVault mounts that tape.

Handling Second Copy Tape Media in OSVault

OSVault has the ability to make two copies of every file, and to make sure that each file is on separate physical media.   There are some good reasons to do this:

• Tape is not infallible, although we have not had an LTO-4 or LTO-5 tape fail on us
• A second copy of files can be taken offsite to guard against catastrophes
• Sometimes humans make mistakes and erase media that is still needed

To Make Second Copies

The first step in setting up second copies is to create a Volume Group called "copy2"
and placing some of the tape media in that Volume Group.  Note that you can put
a tape in this copy2 Volume Group even if it has been used already.

You can then add a second copy tape migration task to OSVault from the GUI by
creating a new tape migration and putting a "2" in the "Extra Copy" field.

How when the task scheduler runs a copy2 tape migration, every file that has already been copied to tape as a primary copy will be copied again to a tape in the copy2 Volume Group.  A separate migration report will be generated if you wish to see the results of that tape migration task.

What To Do With Second Copy Media

Generally, once a tape in the copy2 Volume Group is full (or almost full), you should EXPORT that tape and stored it somewhere else.  There is little reason to leave the tape in the library, since OSVault will not automatically use that tape.  

How To Restore A File From the Second Copy Media

We are working on a GUI button to help with this, but until then a CLI procedure is available to restore the second copy.  This CLI procedure swaps the two extended attributes that show where a file is stored on tape, changing the values of "mig_filename" to the second copy location, and putting the previous primary location in "copy2".  Here's an example:

First make sure the file has a second copy, either by viewing the File Location Report or with the following CLI:

      attr -g copy2 /cache/testfile

Then, you can make the next retrieval of the file go to the copy2 media with:

    PRIMARY=`attr -g mig_filename /cache/testfile`
    COPY2=`attr -g copy2 /cache/testfile`
    attr -s mig_filename -V $COPY2  /cache/testfile
    attr -s copy2 -V $PRIMARY /cache/testfile

Avoiding the Network Stage SCP Hang

NOTE:  This fix is for InfiniDisc/OSVault versions prior to 4.1.12

If you notice that a stage of a file back from network storage is not completing, this might be due to an SSL/SSH protocol issue where the network socket does not close correctly.  The problem has been traced to a standard I/O issue in the DMAPI daemon.     The SSH/SCP program that is invoked is run from an init.d script, rather than a user terminal session.  That causes certain network problems in the programs.

The fix for this is relatively simple, just ensure that the DMAPI daemon is started with its standard I/O redirected to /dev/null.  To do this, edit the /etc/init.d/dmapid file and change the dmapid start line as follows:

Change

/usr/local/bin/dmapid /cache  &

to

  /usr/local/bin/dmapid /cache >/dev/null </dev/null 2>&1 
&

Manually Migrating Files from InfiniDisc to Vault

In some cases, you may wish to move a lot of files stored on an InfiniDisc, via an external hard drive, rather than over a network connection to an OSVault server.   There are several reasons for doing this, including initial setup of an InfiniDisc/OSVault configuration or trying to reduce a large backlog on the InfiniDisc, or just to keep from swamping an Internet connection.

To manually move(migrate) files, you follow a four step process.  First you have to select and copy files to the external hard drive attached to the InfiniDisc system.  This is probably best done in  Command Line Interface (CLI) rather than via a GUI.  Then the second step is to ship the drives to the OSVault.  The third step is to copy off the files from the external drive to the OSVault cache; and the fourth step is to confirm that the files are properly copied and to mark them migrated on the InfiniDisc.

Step One
This assumes that you have hooked up an external drive and mounted it as /tmp/mnt on the InfiniDisc system.  Once this is done, you can run the "find" command on the InfiniDisc to move files to the external drive.  The "find" command used is something like this:
          find /cache/ -type f +mtime +30  -exec /root/test_migrated {} \; -exec cp {} /tmp/mnt/ \; -exec attr -s nomigrate -V 1 {} \;
This single command will search the /cache directory on your InfiniDisc for regular files ( -type f ) older than 30 days (+mtime +30), will see if they have been migrated (-exec /root/test_migrated {} \;) and if they are NOT migrated, will copy them to the external hard drive (-exec cp {} /tmp/mnt \;) and then mark the file as non-migratable (-exec attr -s nomigrate -V 1 {} \;).  Setting the "nomigrate" extended attribute on the file will insure that the InfiniDisc does not try to migrate the file while the external hard drive is in-transit.

Step Two
Unmount the external hard drive, disconnect it, and move it to the OSVault server and plug it in there.  It then gets mounted a /tmp/mnt on the OSVault system.

Step Three
You now need to copy the files from the external hard drive to the OSVault /cache for management.  There are many ways to do this, but a favorite for us is to use RSYNC, so that if anything happens to the copy operation, it can be restarted where it left off, rather than starting from scratch again.  The RSYNC command would be:
           rsync -avz --ignore-existing /tmp/mnt /cache
The "--ignore-existing" flag keeps the system from copying any files that may have already migrated to the OSVault system, or allows you to kill this command and restart it anytime.

Step Four
You now need to tell the InfiniDisc system to check that all the files marked "nomigrate" in step one are successfully copied to the OSVault and to mark them "copied".  You do this with the "net_verify" CLI command.  Net_+verify will search a directory and sub-directories, will find any files marked "nomigrate" and will run a SSH check to the OSVault to make sure that the file is truly copied to the OSVault.  The syntax of the net_verify command is:

                    net_verify -n -s /cache  -f

The "-n" flag tells net_verify to look for "nomigrate" files, and the "-f" flag tells net_verify to mark the files as "copied" if they are confirmed to be on the remote Vault.

The /root/test_migrated script may not be on your InfiniDisc box.  If you, you can create it with a text editor in the /root directory and mark it executable (chmod 0755 /root/test_migrated).  The contents of test_migrated are:

attr -q -g migrated "$1">/dev/null

if [ $? -eq 0 ]

  then

exit 1

  else

exit 0

fi

Labeling Individual Tape Media in OSVault

When adding new media to a tape library, you can always just put the media into unused storage slots using the importmedia CLI command, and then run "check_inventory -l /dev/sg# -f" to find that new media and internally label it.

However, sometimes you need to just put one piece of media in a library, or you just want to check the label written on a tape with the barcode affixed to the tape cartridge, or you want to overwrite the internal label on the tape.

KEEP IN MIND: If you overwrite the internal label on a tape, all files stored on that tape will be permanently lost.

There is an option to the "tape_inv" command to check just one piece of media.  If you run "tape_inv -l /dev/sg# -v VOLUMENAME -d drivename", substituting the volume name you wish to check, OSVault will search the library storage slots and import slots for that barcode label, and then will load that tape cartridge into the first drive and check for an internal tape label.  You must specify the drive name of the first drive, found in the output of the "listdrives" command.

Without any other options, running this command will just load the tape cartridge, read the internal label, and then return the tape to the storage/import slot it came from.

If you specify the "-f" flag to tape_inv, such as "tape_inv -l /dev/sg# -v A000001L5 -d /dev/st1 -f", the media will be loaded, and if not already labelled it will be labelled internally with the same label as the barcode on the outside of the tape cartridge.  This option might be easier to use than the "check_inventory" command at times.

If you wish to recycle an empty tape, you can use the "tape_inv" command to overwrite the existing label with a new label, with the "-f -x -x" option.  The two "-x" flags are required to indicate that you really mean to do this destructive operation.  Once this command completes, the tape media is empty in that cartridge, and future writes will start at the beginning of the tape.  It is also necessary to reset the tape cartridge's database entry to start using that tape again.  A command such as
   mysql -e "update archive.media set Free_Space=\"1666704934\" where Label=\"A00001L5\""
will set the free space on the tape to the default for LTO-5 media.

This tape_inv option is available in version 4.1.7 and later of OSVault.

Future releases of tape_inv will allow you to run the command when other tape operations are active and will not require you to specify the device name for the first tape drive.

Recovering OSVault Archived Files Directly From Tape

There are several situations that can occur that will require you to recover files directly from a piece of magnetic tape, rather than through the disk cache.  These include:
- Loss of the disk cache and related database due to catastrophic failure such as fire or damage
- Export and movement of tape cartridge(s) to another location and desire to import those tapes
- Recovery of previous versions of files that may have been overwritten after initial migration

This post will cover the methods to accomplish the last situation: scanning a tape and recovering all the files on that tape that may have been overwritten later.

Recovering Old Versions Of A File
Recovering an old version of a file can be the most tedious process if you do not know exactly when that version was overwritten.  OSVault keeps a history of the last time that a tape cartridge was mounted, so that information can help to reduce the number of tapes that must be scanned to find an old file.
To scan a tape and recover all the files on that tape back to disk, you use the "tape_dump" CLI command.  There are two ways to recover files from that tape, either as "stubs" or as whole files.  There are different reasons to use each option.  A "stub" recovery, using the "-s" option to "tape_dump", will create a stub file in the OSVault maintained file system but will not read in all the data portion of that file until that file stub is read later.  This allows you to import an entire tape while only using a small amount of disk storage.  Then you can browse the files recovered, and copy/use only the file(s) desired, while not reading all the other undesired files into  disk storage.
You can also recover all files directly from a tape onto disk storage.  This would be used if you are reading a tape into a non-OSVault file system or if you know you need all files stored on a particular tape.  Keep in mind that LTO-5 tapes can have 1.5TBytes of more of files on them.
If you are on an OSVault system, you can use the "-v" option to the "tape_dump" command to have the robotics load the select tape cartridge volume into an unused drive for recovery.  Other operations can be active on the OSVault system at the same tape, such as migration and staging.  So, if you wish to recover the stubs of all files on tape A0000325L5 to an OSVault cache directory called "/cache/recovered_files", you would use the CLI command;
    tape_dump -v A0000325L5 -s -f /cache/recovered_files
This will cause the tape to load into a drive, when a drive is available, and to scan the tape and create a stub in the directly /cache/recovered_files for every file it finds on the tape.  After the tape_dump completes, or is killed with a control-c, the files can be displayed with either the web browser, file browser or command line, and the desired file can be retrieved by copying or reading the file.  That reading/copying of the file will reload the tape in the drive and initiate a staging operation, bringing all the data portion of the file back into disk cache.