TOLIS Group Reseller Newsletter March 2014

NewspaperWelcome to the March 2014 issue of the
TOLIS Group Reseller Newsletter!

There are four topics this month, the announcement of a new, expandable LTO tape library, one that involves your pricing and discounts, and the answers to two questions that we collectively receive.

Also, we will be exhibiting at NAB 2014 in Las Vegas April 7th-10th.  If you are heading to NAB this year, be sure to stop by our booth and say hi.  We’re in the South Hall, Lower in booth SL13105.

TOLIS Group TGL6800X Library Solution

Starting in mid to late April, we will be delivering a new, expandable LTO tape library solution based upon the HP MSL6480 library modules.  Named the TGL6800X, this 6U, 80 slot library is expandable up to a total of 7 units in a single 42U rack enclosure.  Providing a total of 560 tape slots, and up to 42 LTO tape devices - both LTO-5 and LTO-6, the new unit provides a total of 200TB in a single chassis or up to 1.35PB in a fully expanded configuration of native LTO-6 tape capacity.

Because the library can be easily partitioned into distinct sections allowing the assignment of specific slots to specific drives, it is very easy to house a mix of both LTO-5 and LTO-6 technologies within the same configuration without worrying about the tapes getting confused.

The TGL6800X is fully supported by BRU Server immediately upon release.  No updates to the software are required.

Pricing will be announced at the beginning of April.

Important Price List Changes

There are some minor price reductions and new ArGest® solutions for the M&E Industries that are NOT reflected currently on the online Reseller Resource.  Also, we are now providing discounts based on a “levels scenario” that are not shown on your current price lists.

Until we distribute the new price lists, please contact your TOLIS Group sales representative when quoting solutions to assure accuracy.

Positioning BRU

The questions we are asked are the same as those you receive.  One of the recurring questions we field centers on using BRU versus other formats to write to tape.  Recently Tim Jones, president/CTO of TOLIS Group published a blog that addresses the topic beyond the promises of glossy marketing materials, and its essence follows:

Being able to restore data is the reason that you perform backups/archives in the first place. If TOLIS Group was selling product that was only as reliable as the work created by other people that had no responsibility for the restorability of our customers' data, I'd actually be a bit scared of every phone call that our support team handled. Of course I'm very proud of the fact that BRU was created to alleviate the issues that existed in previously available tape formats - we didn't simply ride on top of an existing format that was prone to failure just because everyone else rode on that same fail-prone train.
When you look at solutions that are simply wrappers on top of TAR or LTFS (meaning that the provider didn't actually write their own archive container format), you have to wonder how much the provider understands about how data is handled with relationship to the physical tape interface. After all, the success or failure of their product from their customers' perspective is completely dependent on whether that 3rd party format works properly. With both the BRU archive container format and the core I/O application, we offer almost 30 real years of experience with both the software and low level SCSI I/O communications engineering combined with hardware design and engineering knowledge of all tape devices (not just LTO) to provide the highest level of reliability because we know exactly how each byte of data is written into the archive container format and how that I/O interacts with the tape drives themselves. Tape drives offer a wide variety of health and status options while data is being read or written. Unfortunately, TAR and LTFS don't take advantage of these features (you can retrieve the source code for both to verify this claim).
Aside from BRU and Retrospect, all other solutions that I am aware of for the Mac OS X environment are dependent on TAR, CPIO, or LTFS. TAR and CPIO formats were created when archives were measured in KB and tape devices were very basic in their I/O support. Products based on these formats have run into the limitations those designs create more than once. LTFS is really nothing more than a copy program with a volatile driver layer that is dependent on too many hardware vendor's disparate engineering teams. BRU was created from the start with the understanding that data was potentially infinite. We supported 64bit environments all the way back in 1994 and the current version of BRU can deal with 16 Exabytes of data in a single archival stream (not something we recommend, however). Additionally, BRU continuously communicates with the tape drive during I/O operations to make sure that things are working as they should. We have very aggressive retry mechanisms and know what steps to take if those retry mechanisms fail.
Another serious issue with LTFS that no one seems to discuss is the complete lack of support for even basic filesystem permissions, let alone enhanced capabilities such as ACL (access control lists) and EA's (extended attributes). With LTFS, these are simply ignored and discarded. Additionally, symbolic links (referenced files or aliases in OS X) are not supported, nor are special characters such as the bullet (OPT-8) that Mac users often use when naming files. From the current LTFS documentation:
File permissions

The LTFS application manages a common set of file permissions for all files and users; file and directory ownership is not recorded to tape. The only permission that is tracked is write-protect information. Files or directories that are write-protected have their permission bits set to 555; write-enabled files and directories have their permission set to 777. By default the user and group information is set to that of the current user; this can be overridden by use of the -o uid and -o gid options to the LTFS application.

File types

The LTFS application does not support the creation of symbolic links or hard links within the tape file system. Attempting to create a link or copy a link to tape will result in a “Function not implemented” error. If using the cp command to copy to tape, the ‘-L’ option may be helpful to follow symlinks.

The LTFS application also does not support creation of special files and will report “Function not implemented”.

File names

To maintain compatibility when copying files between multiple platforms, it is strongly recommended that the following characters should not be used in LTFS for file names, directory names, or extended attributes:* ? < > : " | / \

Note that the documentation entry for filenames doesn't mention to not use non US-ASCII filenames, but that is what it actually boils down to. If you use non US-ASCII (UTF-16, special characters, or reserved characters), your copy operation will fail. However, properly handled by the archive container format, all of these characters can be dealt with on all three supported systems.
With BRU, all permissions, ACLs, EAs, Finder Info (tags, comments), and resource forks are properly included and processed in the archive that you create. Any character that you can use on your system to name a file is properly handled. All supported filetypes are properly archived and restored.
Relate/share this information with you clients when questioned.  You will not find yourself in the position to defend BRU.  
BRU ... because it’s the RESTORE that matters.

LTO-7 Availability

A question that is surfacing with greater frequency lately involves the availability of LTO-7.  We will provide a more complete perspective in next month’s Newsletter, but for now the short answer is: LTO-7 shipments will realistically begin in late 2015 or early 2016.

TOLIS Group at NAB 2014

TOLIS Group will be exhibiting at NAB 2014 in Las Vegas April 6th-11th.  If you are at NAB this year, be sure to stop by our booth and say hi.  We’re in the South Hall, Lower in booth SL13105.

Author: Anonymous

Copyright © 2012 Ronver Systems | sitemap | site by MoonWorks