ITSM and NetBackup : Feature Comparison

Feature Comparison

Aspect	ITSM	NetBackup
Backup Methodology	Incremental only backups, time-aged archiving, and full HSM support	Traditional full, incremental/differential. "Archiving" is backup and delete.
Overall design	TSM is a monolithic product, written and marketed by one company. This means, in general, that the interfaces presented are consistent and clear.	NetBackup is an amalgam of two main products, Volume Manager and Backup Plus. As such, the interface can appear to be fragmented and inconsistent.
Resource Consumption	Being very database intensive, TSM requires large system resources for the server. CPU, RAM, I/O bandwidth and good physical database layout are important.	The catalog is a simple set of mostly text files, and is not used extensively during backups. NetBackup 4.5 introduces a binary catalog format, for space and performance reasons. I/O bandwidth is the main concern.
Point in time restores	As the TSM database maintains a snapshot of which files existed within each filespace at the time the last backup completed, a point-in-time restore will only restore those files.	As NetBackup uses a traditional full/incremental cycle, multiple restore cycles may be required, and files deleted from filesystems between restores will still exist on the restored system. This can make systems with a high file turnover difficult to restore. NetBackup includes a feature to work around this, True Image Restore (TIR), which needs to be enabled during backup.
Multiplexing	Multiplexing is not required, and does not make sense, with TSM. Slight Correction: Multiplexing has been introduced for the SAP R/3 TDP, where it does make some sense; allowing multiple client-compressed data streams to run directly to a single tape drive.	Multiplexing is supported, and may be required when backing up multiple slow clients simultaneously to allow tape drive streaming, and also to allow many clients to fit within a backup window. This may have a large impact on restore times.
Tape consumption	As reclamations must be run as part of normal TSM operations, free space on tapes can be kept to a minimum. Also, for normal incremental backups, only one copy of each version of a file is kept in each copy pool.	Given the requirement that full backups must be periodically run, there is the potential for many copies of exactly the same files to be kept on tape, wasting valuable tape capacity.
Network utilisation	As only changed files are sent over the network, traffic is kept to a minimum. Additionally, client-side compression can further dramatically reduce traffic, and sub-file backups can be used over slow WAN links.	As full backups are required periodically, network usage can be far greater. Backups over WAN links may be unpractical.
Retention management	For backups, four values (versions data exists "VERExists", versions data deleted "VERDeleted", days extra versions "RETExtra", days only version "RETOnly") are set to define retention characteristics. These may be set on an individual file-by-file basis. Moving backups between servers can maintain all retention information.	Nine retention levels are defined in NetBackup v3.4, and may be customized. In version 4.5, this was increased to 25 levels. It must be remembered when moving data between servers that the retention levels are specific to each server.
Configuration Clients	A TSM server may be administered via two main methods: a single command-line interface with a rich command language, or a web-based graphical interface	Five main configuration methods exist: the various command line tools and menu systems, an X-based GUI with a slightly limited view of configuration, a Java-based GUI with a different presentation of the configuration, and a Win32 administration tool.
Configuration complexity	TSM is a large, feature rich, complex product. As such, understanding the concepts, abilities of the product, and methods of achieving goals, may take some time. However, once familiar with the concepts, installation and configuration is a moderately complex task.	As a group of tools, NetBackup can be difficult to manage. Each administration tool or interface presents a different view of the configuration, and not all methods allow the viewing or changing of all parameters.
Debugging	Almost all useful information is to be found in four places: the client log, the client error log, and server activity log, and the server error log. Additionally, there are many internal undocumented trace and debugging facilities, which vendor support may utilise. Some documentation may be found here.	Logging may be turned on in various components which may generate extremely large log files. Often, errors may go unlogged, and must be found by other means. I have seen on several occasions, unknown and undocumented error codes logged.
Scheduler	A fairly simple and powerful scheduling system is included, for both client operations and server operations.	The scheduling system was completely replaced in version 4, as the version 3 scheduler was well known as being broken in a variety of ways. Due to the requirement of regular full backups, the schedules may need to become large and complex to stagger full backups, to reduce network and tape drive contention.
Offsite support	DRM is an integrated capability. It becomes an additional layer within the storage heirarchy. Data may move in both directions, onsite tapes copied to an offsite tape pool, and damaged or lost onsite tapes may be rebuilt from offsite tapes. Database tracks locations of individual files, whether onsite or offsite.	In version 3, vaulting was an after-market add-on. It was complex and and temperamental. In version 4, it has become a built-in component. Under version 3, tracking location of offsite data was left up to the user, I do not know if this has changed in version 4.
Scaleability	If the posts on the ADSM-L mailing list are to be believed, there are many sites backing up over a thousand clients to a single TSM server, with some clients on WANs and mobile clients. There are other sites backing up multi-terabyte SAP instances nightly. It appears, if TSM is well configured, it can scale very well. TSM started as a Hierarchical Storage Manager on IBM mainframes, and has grown downwards to become a general backup tool.	Due to full backup requirements and scheduling constraints, it is hard to see how NetBackup can be seen as an Enterprise class backup system. NetBackup started as a backup system ideally suited to backing up a handful of related systems. It has then been expanded and pushed into the Enterprise arena without changing many of its fundamental design decisions. It is debatable whether it is as yet truely an Enterprise class tool.