Tim Jones
Forum Replies Created
-
We’re not gone and BRU’s not dead :). Keep your eyes peeled for an important announcement this week.
-
Hi Simon,
Open a support ticket and the team will be happy to help. Also, the entire back section of the BRU PE User’s Guide is dedicated to command line operation.
Also, after you’ve run an Import with the Tape Import Tool, please backup your BRU PE environment (/Library/Application Support/BRU PE) and attach the resulting backup to the ticket so that we can take a closer look at what failed.
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters! -
Hi Jon,
Yes it is and I show that you are on both the Beta and the Announcements lists. I it possible that we ended up in your spam/junk folder?
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters! -
[Jim Curtis] “Is anything in this article inaccurate? I’m open-minded about changing, although at this point, I have a fairly significant number of BRU tapes I’d have do restore and re-write in LTFS.”
As I’ve stated publicly many times regarding that paper and my LTFS Caveats piece – if anyone can refute any of the points, I’ll gladly update and/or remove them. My goal in sharing the information is not BRU world dominance, but rather that potential tape users have the full facts.
We’ve been at this tape game for more than 35 years, and we’ve seen a lot of “tape as disk” options come and go. This is why BRU is still the same BRU that it was in 1988 and why the BRU engine that you use today can restore data from tapes that were written to a 250MB QIC cartridge in 1990 on an SCO XENIX system. At this point, you can’t even restore from an LTFS tape that was written just 6 years ago unless you have the old LTFS code and the knowledge to compile and install it.
BTW – Jim, Marcos and Eric send a great big thanks for your feedback and Eric said to tell you they’ve found the errant entry that caused that odd restore issue.
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters! -
I don’t know if you can run LTFS packages on your new Mac Pro yet, but its a good bet that the market will cause open source solutions to get there quickly whereas it may take Bru more time.
Tom – BRU’s been on Catalina since long before launch (unlike LTFS). It was simply the GUI that was held up due to Apple throwing us all (meaning ALL Apple developers) some new curves in the form of the protected union filesystem mounting and refusal to allow any 32bit code on the new system.
As for the state of things now, BRU’s new workflow wrapper is our new “ArGest® Backup” suite. It’s available and a good number of existing users are already beating the heck out of it with use on macOS, Windows, and Linux.
You also state –
“It is possible that LFTS might screw up more than a stable Bru configuration, but if you verify your archive upon completion this is a non issue.”
– but the question is exactly HOW do you do that? Compare all of the files? Create MD5 or SHA256 sidecar files and then recheck those? And what about in 2 years? With BRU this is all self contained and automatic.
Remember, as in science lab – be sure to check your facts and sources. 😉
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters! -
I would have loved to have had out team be able to examine that tape. Unless the tape itself was aggressively degaussed, the drive should have been able to find the servo tracking information and at least been able to give you the hard format header info. Granted, I have some magic in my drives because I was part of the team responsible for the original design in conjunction with SGI and HP, and I can coax a bit of recovery efforts from them, but I’ve never seen a DAT tape just “lose” it’s tracks and data unless it was horribly mishandled. I still own the first customer unit DAT from our Maynard division (complete with the ADAT digital audio I/O port for SGI in our lab.
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters! -
The problem is even simpler than that – the H1280 is a PCIe 3 HBA. Your Mac only offers PCIe 2 slots. You will never see the performance you expect out of that HBA on a Mac system. While it may “Work” it’s severely hampered by the x4 PCIe 2 slot you have available on that system.
So far as your BRU Server configuration, you’re running about as good as you’ll get until you can move to a platform with true PCIe 3 support. The only change you may wish to try is if the Server and Client are the same system, be sure that you are using “localhost” or 127.0.0.1 for the network setting for both ends to keep the traffic internal to the system’s network stack.
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters! -
As Tom mentions – just because the vendor is gone, doesn’t mean that existing devices cease to function. And, in the case of Cache-A, even if the Cache-A devices fail, the tar and LTFS tapes can be accessed by other systems (unlike Quantum’s DLT-A and LTO-4A devices).
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters! -
Bob,
That post is a bad example and Barry has been hit by some serious issues with our prior outdated system (from 2004). I don’t respond to Support Requests here generally to maintain my position as vendor neutral. TOLIS Group is still alive and well and the support system has been replaced with a modern 64bit server with a modern LAMP stack and the latest version of osTicket. You can open a ticket and get a response at https://support.tolisgroup.com.
Also, regarding technology obsolescence, we have LTO-1 drives from 2001, AIT-2 drives from 2002, DLT-80 drives from 1997, 2GB DAT drives from 1991, and 250GB QIC cartridge drives from 1988 that still function properly and allow our current version of BRU to restore the information that was recorded onto their respective tape formats. Not all technology goes away simply because vendors release new formats. Think about that – a 2GB DAT tape that was recorded in 1992 on an SCO XENIX system is still recoverable on a 2018 Linux system.
The big issue with cloud that is not on-premises will always be bandwidth. When a relatively modest wedding shoot brings in 4-5TB of multiple camera data, there’s no way to get that data onto your cloud storage before your next job adds that much more data. Imaging trying to manage that when shooting a larger production.
While nothing that has been mentioned about disk is incorrect, many myths about tape storage are.
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters! -
Hi Shaun,
That is dependent on your environment – including the platform and data types. I assume that since you’re using the H1280 you’re running on a Windows or Linux system.
For Linux, you will run into kernel and sg settings walls. We’ve noticed that most 4.x kernels won’t allow buffering above 512K unless you know what to change in the sg/st layer and can recompile your kernel.
For Windows, it will depend on whether the software is running using the mini port drivers or the WIN32 tape API/SDK. In our tests on Windows 10 and Windows Server 2012 and newer, 512K seems to be the sweet spot – assuming that you are retrieving the data from a storage system that can deliver a sustained read rate of 500MB/sec or better.
In any case, backing up media files that are in the 50MB+ per file range will provide reasonably good throughput while backing up a non-Exchange email server will suffer from the extreme number of disk bottlenecks related to the file access overhead.
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!