Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Backup and Tape device answers

Hi Tim, Is there any plans for Bru releasing stand alone software for windows by any chance?

Stricko
 
The restore did complete - a restore reports "Files read" as you're reading the archive. As to the apparently "missing" restored dara, that's an issue with BRU's restoring EXACTLY what it backed up in LE. If you go into a Terminal and look at the restore path you specified, you'll find:

Code:
/Volumes/WDTB/TestLTO/Volumes/SamsungHD/ExportedMovies/TestMovie_LowRes.mov
Because the Volumes folder is a hidden folder, BRU restores it hidden.

In BRU PE, when you specify an alternate path and select a specific file, the file's original path will be truncated. That means that this restore ni BRU PE would have resulted in:
Code:
/Volumes/WDTB/TestLTO/TestMovie_LowRes.mov
- which is, I'm sure, more in line with what you expected.

Once BRU PE is launched, a new version of BRU LE will be heading out with this same change. For now, you'll need to use the magic Finder "Go to folder" option (Command-Shift-G) and move the file to the proper location.

There's more on this in the following knowledgebase article on our website:

http://knowledgebase.tolisgroup.com/?View=entry&EntryID=161

Tim

Thanks much, Tim. Got it.

Murali
 
I'm looking to get a LTO-4 for my MacPro here. I'm looking at this set up, any feed back?

- HP StorageWorks LTO-4 Ultrium 1840 SAS External Tape Drive EH861A#ABA
- ATTO EXPRESSSAS R348

Retrospect + BRU-PE (when available)
 
I'm looking to get a LTO-4 for my MacPro here. I'm looking at this set up, any feed back?

- HP StorageWorks LTO-4 Ultrium 1840 SAS External Tape Drive EH861A#ABA
- ATTO EXPRESSSAS R348

Retrospect + BRU-PE (when available)

I'm thinking of that combination, too, especially I have metaSAN running with ATTO Celerity card. Keeping the host bus card from the same company for RAID and tape backup.
 
Hi everyone,

Thanks for the good information in this thread. I have been trying out Symantec Backup Exec for windows server. It seems like a comprehensive, and importantly - easy to use backup system, with verifys, easy restores, good databases. etc.
Does anyone have any expereriences to share, good or bad, with this software?

Best Regards.
 
No standalone Windows for now

No standalone Windows for now

Hi Tim, Is there any plans for Bru releasing stand alone software for windows by any chance?
Not at this point - however, I won't say never. It's the scenario where a small old-world Unix shop would be overwhelmed by the potential of 800+ Million Windows users deciding they wanted to give us a try :ohmy: .

However, as we grow, the unavoidable nature of the beast may just consume us regardless of our plans.
 
HP and ATTO a great combination

HP and ATTO a great combination

I'm thinking of that combination, too, especially I have metaSAN running with ATTO Celerity card. Keeping the host bus card from the same company for RAID and tape backup.
I agree fully with this. Plus, ATTO has some of the best support for all Mac users of any hardware company out there. HighPoint comes in second, but their HBA's don't provide tape pass-through support.

As the selection goes, BRU loves that configuration. In fact, I use the ATTO / HP LTO-4 as my main personal backup solution.

Tim
 
Hi Tim,

Thanks your for kind help. Here's a newbie question : when archiving files on LTO-3 for long-term, is it better to choose uncompressed or compressed mode on tape ? I'm not talking about TAR/ZIP/etc... here, just the compression on tape. Is there a reliability difference over time ? Thanks !

Kristin
 
when archiving files on LTO-3 for long-term, is it better to choose uncompressed or compressed mode on tape ? I'm not talking about TAR/ZIP/etc... here, just the compression on tape. Is there a reliability difference over time ? Thanks !

Kristin

Hi Kristin, not intending beating Tim to the punch but I would suggest that because the material we work with is highly uncompressable by the tape drive's string (LZ-1?? etc) simple compression schemes.

There is no advantage of using any kind of tape drive compression the material we use unless they are easliy compressible such as typical I.T. type of documents they are full of repetative patterns.

If you have an option I would recommend you TURN TAPE COMPRESSION OFF. (tape_drive_compression = false; ) . You will save some relieve overhead in the tape drive controller and maybe see a miniscule of a performance increase.

hth

w
 
Hi Kristin, not intending beating Tim to the punch but I would suggest that because the material we work with is highly uncompressable by the tape drive's string (LZ-1?? etc) simple compression schemes.

There is no advantage of using any kind of tape drive compression the material we use unless they are easliy compressible such as typical I.T. type of documents they are full of repetative patterns.

If you have an option I would recommend you TURN TAPE COMPRESSION OFF. (tape_drive_compression = false; ) . You will save some relieve overhead in the tape drive controller and maybe see a miniscule of a performance increase.

hth

w

Warwickt,

What if the materials are mainly DPX? I realized when I was sending some DPX materials to the clients, zipping it made them significantly smaller, so I was wondering if tape media compression has some effects on that.

I agree with QT clips and the similar won't take advantages on the compression.
 
Warwickt,

What if the materials are mainly DPX? I realized when I was sending some DPX materials to the clients, zipping it made them significantly smaller, so I was wondering if tape media compression has some effects on that.

I agree with QT clips and the similar won't take advantages on the compression.
Hi Kaku, well as I said anything with extensive repeatable patterns will gain from the simple string compression in the latest data tape drives.

workflows: In any case the tape drive compression is ON or OFF until you selectively switch it with a tool or .app so not so flexible for a bunch of archive material I think as workflow.

Aside from the data tape drive compression you might want to consider OPTION#2 later in this post.

ZIP and other compressors are far more sophisticated than the simple real time string compressor in the tape drive. I am uncertain of the more recent technical details , but the string lengths are LIMITEd that it searches for compression. I'm sure you can dig up material on this if you hunt around. Suggest you check the IBM, SUN/STK and HP SWD sites for this the detail.

OPINION: I guess if you have a lot of them then certainly worth a try I don't know what the worth of doing this is these days especially when the material is usually complex and uncompressble and more so the capacity of the data tapes is quite large.

It depends what yur goal is whether or both:
  • compressing to put MORE on the data tape medium and | or
  • compressing to improve data transfer efficiencies (in some cases I would think this is relevant) - regardless of the performance hit on the tape drive(??)

Other issues come into play for point #1 namely the BLOCKSIZE used by the application to write the data to the tape drive. Simply a large data tape blocksize for material whose entire size may be less than the block size is wasteful for the tape media.

Inversely a large object with small tape data blocksizes (same as in the old days with soft/configurable disk sectors)

I guess it is worth for you to test this out for yourself. I would be interested for curiosity sake only.:nerd:

The software I use doesn't permit the tape drive compression to be disabled. It is however a straight forward mode_select_page operation if you want to write some code.

OPTION#2 - use archive application's software COMPRESSION scheme. It has these benefits:
  • performs a much better execution of compression more in the lines of what you where expecting with apps you mentioned
  • ability to SELECTIVELY compress items in an archive I would think this would be suitable for your needs above
  • maybe configurable to 'compress to taste" option...

A disadvantage is that because the archive/backup software.app is performing you might wanna consider:
  • greatly increased CPU over head whilst it deals with the compression
  • thats the compression is proprietary (as are many solutions)
  • that the overhead to DECOMPRESS the material is also done in sofwtare by the archive.app and ths in initial point causes an increase in CPU overhead.

I use Tolisgroups BRU-Pe (Beta) and It is one such archive/backup up that permits optional compression of archives in software. I dont use this software compression option myself.

HTH
w
 
To compress or not to compress, that is the question

To compress or not to compress, that is the question

Hi Tim,

Thanks your for kind help. Here's a newbie question : when archiving files on LTO-3 for long-term, is it better to choose uncompressed or compressed mode on tape ? I'm not talking about TAR/ZIP/etc... here, just the compression on tape. Is there a reliability difference over time ? Thanks !

Kristin

While Warwick hit it pretty much on the head, it's a simple choice - leave the tape drive alone (never use software compression when using tape). Tape drives have intelligent, adaptive compression, so they monitor the incoming data stream and adjust themselves appropriately - they all know when data is not compressible, so they don't try. However, a good bit of the data in the stream IS compressible - metadata, filesystem info, session files, so by allow the drive to do it's thing, those bit will be compressed saving some space over completely disabling the drive's hardware compression.

However, one thing that is slightly off the mark is that the compression in the drive's hardware isn't a simplistic algorithm, but rather a fairly aggressive one (considering its lossless nature). It's just that the drives have a dedicated uP inline that does nothing but deal with the compression process. That's why you should always select hardware compression over software compression when you need to make a choice. The hardware compression will almost always win out over even the newest systems compressing while using their normal CPUs. As Warwick said - letting the drive do the work offloads the compression work so there's less affect on your system during the backup and, at least with BRU, you can still do productive work while the backup runs.
 
Are there particular benefits to using PC versus Mac to run your LTO-4?

Are there particular disadvantages to using PC versus Mac to run your LTO-4?

thanks,
Paul
 
Are there particular benefits to using PC versus Mac to run your LTO-4?

Are there particular disadvantages to using PC versus Mac to run your LTO-4?

thanks,
Paul
Hi Paul sure there are several advantages to using windows over other platforms.. mainly due to availability and variety of options only? for a backup/restore.

I'm an *MACOS guy so I'll be as objective as possible.

Simply:
  • a great deal of SAS PCIe HBA's are supported | managed| configured under microsoft platforms and solaris, and various linux as well. Particularly LSI, ARECO, ADAPTEC and many others including ATTOTECH. IMPORTANT THOUGH TO LOOK HERE FOR SAS TAPE DRIVE SUPPORT (TApe drive pass-through)
  • most of the SAS tape drives have firmware and management support under windows os's particularly , less with others
  • and lastly there is a plethora of BACKUP (not archive) software available for windows platforms due to the ubiquitous nature of microsoft os's in the commercial I.T world. THere;s so many out there . One that supports tape drives and libraries is Symantecs BACKUP exec. There are loads of others but these dont run on MAC OSX platforms sadly.
ULTRIUM LTO4 tape drive SPEEDS and FEEDS are identical for tape drives between OS's.

SOFTWARE: However functions in COTS archive and backup software applications vary as much as say a word processor.app. especially in those areas of:
  • tape devices supported
  • tape libraries that are supported
  • tape library controllers servers tat are supported
  • tape drive enabling enhanced functions
  • GUI usage
  • backup vs archive notion
  • lots more

In the .I.T world where these tape drives are extensively used and have been used now in some form for 50 years, theI.T. worls is mostly (bit not always) geared to BACKUP/RESTORE. THeir needs are greatly different and as many will agree I think, that as microsoft is entranched today is where thw COTS software backup bendors have concentrated. THeir workflow is different from the like of us in the creative world (sorry for rant).

I'm sure Tim will weigh in here as he has loads of experience here.


Overall there is much more support and options under microsoft platforms and solaris and linux as well.= from configs, COTS sowtware and HBA vendors..

Some of this thread and many like it have been disussing archieving systems and in particular configurations that actually work using LTO4 Ultrium and other tape drives in a mainly  MACOSX environment for use in creative environments.

If you are using windah's os our very safe indeed for utilising some archive/backup on data tape as there are many good options for you.

I use MACOSx platform creative workflow tools .. not any windah's %^%^@ seen anywhere here :)

HTH.
w
 
It's all about the drivers

It's all about the drivers

As Warwick stated, there are solutions for both platforms, but Windows does offer more choices. However, from my experience, more choices means more potential pitfalls. There are many SCSI and SAS HBAs available for Windows, but with those choices comes the issue of drivers and Windows versions. Also, most Windows backup software, in an attempt to work around these driver/Windows variations include their own device drivers. And therein lies another potential for problems - does the software's device driver support the drive or library that you're using?

One thing that Unix-based platforms bring to the table is a very generic driver model. This means that Solaris supports DDS-1 DAT as readily as it supports the latest LTO-4 technologies. Some of them allow you to "fine tune" your settings for optimal performance, but in most cases your tape drive or library will work right out of the box.

Luckily, Mac OS X is a Unix based platform and, while Apple don't provide native tape support like Linux or Solaris, they do provide a stable API for accessing the tape and library devices. As an example of that stability, we haven't had to change one line of code in BRU since OS X 10.2.5 was released. And, our code is still compatible with the upcoming Snow Leopard (10.6).

The final piece of the puzzle is the tools required to manage and diagnose the tape and library devices themselves (outside of normal backup/archive operations). This is where Windows and Unix win hands down over Mac. However, we (TOLIS Group) are working with all of the major device manufacturers to get those diagnostic tools ported over to OS X.

In summary, no matter which platform you use on a daily basis, you can probably provide an archival/backup solution without the need to change platforms. The important point is to check with your software vendor to ascertain compatibility with the devices that you wish to use.

Luckily for BRU users, the answer on OS X and Unix is simply "Yes, we support that."

Tim
 
I use Bru server in a number of facilities and can recommend it to any one here for media use. We don't get many problems with it. My only comment is it requires a little Unix knowledge to support any command line work for any problems that may arise. With any back up and/or archive solution some background knowledge is needed to correctly understand the processes that need to be set up for best performance.

Some years ago I originally had doubts about using an OS X machine for back up but its been no problem at all.
 
Back
Top