Tape is still relied on by companies of all sizes as an archive and data storage solution and has been for around 60 years. High durability and low cost compared to other storage technology present themselves as clear advantages; however this also can pose as a stark disadvantage that is often overlooked. Why? Over the years many companies have gathered lots of different tape formats as well as different tape backup solutions like Commvault, IBM Tivoli Storage Manager (TSM) or NetBackup, just to name a few. In many (if not most) cases companies are facing the problem that due to regulatory or compliance reasons they have to keep access to many old legacy tapes from different vendors.
Too many vendors spoil the broth
Due to this, companies who store a lot of legacy tapes have to maintain the necessary hardware and backup software in order to access the data on their tapes. Subsequently, they have to pay licences for all of the different backup solutions they still use. Due of this, many companies try to consolidate their different backup solutions under a single vendor solution, or into one tape type.
So when companies start thinking about a tape migration, big problems start becoming apparent. For example, before an administrator can begin they have to plan ahead and consider if there are proper records that show the details of the archive system: do the tapes have the same format? Do they use the same vendor backup solution and version? Are all the tapes and tape drives still functional? How many tapes are there and what data resides on each one?
If all tapes have the same format (LTO5, DLT, etc.) and have been kept in good condition, then several problems are nonexistent and you can move on. If not, the tapes may need to be checked or even repaired to access the legacy data. Normally companies should still have the necessary hardware available to access all the different tapes however this may not be the case for older tape formats.
So if one tape backup solution is changed to another, will the data be stored on tape again, or should this be changed to some form of hard drive-based system? If the post-migration destination is still tape, a decision should be made on which format the data will eventually be stored. It usually makes sense to use the latest and most common tape version available on the market – LTO7 at the time of writing. A typical tape migration scenario would then look something like this:
- Retrieve all data from the archive tapes
- Consolidate and migrate the backup data from the legacy vendor backup solution to the new one
- Backup all consolidated data to a common tape format and using one vendor software solution
When such a project is finished the end result is one common, tape-based backup solution as well as all tapes being a single format. Legacy backup applications then become obsolete and can be retired for good, reducing infrastructure costs and eliminating maintenance fees.
How do you migrate from a Commvault backup solution?
Migrating data from an existing Commvault backup solution to another system will normally be done in the traditional way. First, you have to access or create a full backup with the Commvault system and restore all the data stored inside the managed tape library. Once you have restored all of the data and archives onto alternative (temporary) storage space (could be on disks from your local SAN/NAS), you have to build the new backup system (both hardware and backup software) from scratch, create the archive structure and import the data into the new backup system.
Additionally, all necessary clients, policy details and schedules, tape inventories and catalogues have to be generated. If you consider changing to a new system some hardware and backup software providers offer specialist migration services, which in some cases will result in a significant part of the total migration cost.
Whether it is one of the older software packages or the new Simpana release; the most common solution to migrate your backups is to use your existing Commvault package to restore your data to a new location and re-backup using your new vendor solution. Even though there are some software solutions on the market which offer to ‘translate’ the Commvault settings and structure (as well as the actual data itself) it is often not viable in terms of time and costs. What’s more, if the process fails when using one of these software tools it is possible to damage or lose valuable data and/or Commvault settings. Also, like all other backup software solutions, Commvault uses special data formats which compress the data stored in the backup. When the data structure is destroyed it then becomes a very difficult task to recover the backup structure as well as the data. It’s comparable to finding a needle in a haystack!
What about migrating to Commvault?
Migrating data from a different product like a current Tivoli TSM, NetBackup or NetWorker backup solution to Commvault is a little easier. With its ‘External Data Connector’, Commvault enables new clients of its latest Simpana backup software to import not only the data stored inside a backup but also the other details about the current TSM, NetBackup or NetWorker storage structure, such as client information, policy details and schedules, job information and tape inventories. With this information available, it’s possible to then translate the old clients to Simpana clients, deploy the client hardware and inherit the defined policies from the old TSM, NetBackup or NetWorker system. However, in the unlikely event that a migration doesn’t work because of hardware or software failures, problems can occur that even an experienced IT administrator cannot solve by themselves.
Let’s take an example: broken tape library linkage or tape catalogue files make it hard even for experts to recover the original structure of the whole backup system and the attached tape library. If a migration from TSM, NetBackup or NetWorker backup to Commvault stops in the middle you can be in serious trouble. There still may be hope though – data recovery experts can in most cases recover data in this scenario, as well as making sure the rest of the tape migration process completes successfully.
As you can see, there rarely every going to be a ‘typical’ Commvault migration project, no matter which way you’re moving the data. What you will find though, is it’s likely to be a time consuming and costly task. The decision for a migration project should be based on if you are planning on continuing to use tape media as your archive storage solution, then you can base the project around your chosen media type. In some cases it is required by regulatory or legal requirements to maintain access to data in the long-term (which tape is perfect for), but in many cases having a fully functional tape backup solution, together with the necessary hardware is not always necessary.
We’ll come back on this subject in another article, where we’ll describe what a migration project to or from Tivoli Storage Manager might look like, plus what other solutions are available that could help to reduce the overheads associated with legacy data management.
Has your organisation performed a Commvault migration in the past? What challenges did you face and how did you overcome them? Let us know by commenting below, or tweet @DrDataRecovery