-
Not sure what to do with TAR tapes written with Cache-A. Now have BRU.
I have been using the Cache-A to write TAR tapes for the past 3 years, currently have 30 sets of LTO-5 tapes that span 60 tapes with both masters/clones.
Long story short, the Cache has been causing problems after the first year of use. The device can no longer reliably write tapes, but I have no issues reading them that I am aware of. I had the Cache repaired, it worked fine for 2 years, and then it seems that the writing ability of the device has failed again. We have since upgraded to the BRU since ProMax support has been horrible with our Cache and their solution is to just buy a refurbished model of the exact same one we have to ensure compatibility.
New problem is that the TAR tapes that we wrote on the Cache are not ingesting properly when restored using the BRU and Argest Ingest. Files are missing because the TAR process cannot find all the archive sets on the tape. Not good.
So what do I do from here?
a) Maintain my old Cache-A machine to read my library of 30 sets of tapes?
b) Copy data off all 30 tape sets with Cache, use brand new LTO tapes to write them using BRU PE
c) Copy data off all 30 tape sets with Cache, re-use same tapes using BRU by overwriting themA could potentially cost $2,500 to get a refurbished device down the road if our current Cache fails, or it works just fine for the foreseeable future and has no cost. B would cost about $1,200 to buy all new tapes. C would be free, but not sure what issues would come up with formatting TAR tapes to write over them with BRU PE. I am also concerned about the reliability of the copying of files off my TAR tapes with Cache since it has given me problems with writes in the past. Not sure if it is a software problem or the write head failing. The idea of re-writing tapes is a little scary just in case the Cache fails to read data on the tape like BRU Argest Ingest had issues with. But I guess that data would be gone forever anyway if it can’t read it?
Any advice, or is there an Option D I am not thinking about? Just move back to using multiple sets of external hard drives?
-
12 Replies
-
Mike-
I can see where you have many areas to be concerned about. There are a couple of suggestions I have. First would be to move all of your media assets to an external drive, even if temporary, until you have a solution you feel comfortable with. If your Cache-A device is still reading currently, you should be able to do this with no issues. This way, you buy yourself time to find and educate yourself on some options that would be the right fit moving forward. Second, Piston Media Group offers a wide range of solutions when it come to storage and archive of media. While we are a reseller and integrator, our biggest focus is on being a resource for our customers and making sure they feel that they are making educated and confident decisions with their media technology and workflows. Please feel free to reach out to me any time and we can talk about your current obstacles and some possible low cost solutions for you to look into. In the mean time, I wish you the best of luck in getting your problem solved so you can get back to focusing on what you more than likely do best, being creative.
Josh Phillippi
Piston Media Group
(888) 829-7320 x101
(818) 318-8211
jp@pistonmediagroup.com
https://www.pistonmediagroup.com -
You could always just restore the Cache-A TAR tapes using the TOLIS Tape Tools that are included in the BRU PE package. While the default requires using the command line, we offer an add-on for BRU PE named ArGest IngestPRO that gives you a GUI front end if you’re either not command line savvy, or have more than a few tapes to deal with.
An example of restoring a Cache-A tape from the Terminal would be:
cd /Path/To/Restore/Location
taperead -f ntape0 -b 150K | tar -xvvf - -b 300
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters! -
I tried using ArGest IngestPRO due to me not being very terminal savvy, and it didn’t unarchive more than half of the files on the tape! I tried unarchiving an entire tape that just had raw camera footage on it, since I know the file structure was simple and the file names were sequential. The entire copy from the tape was just missing random files from every folder. I went back and unarchived using my Cache to confirm that the tape wasn’t corrupt. The Cache unarchived the tape just fine.
The interface of ArGest IngestPRO is very simple, so I know it couldn’t have been user error. I am just assuming that the it has something to do with how the Cache wrote the tapes and ArGest IngestPRO’s inability to read the data segments.
-
I believe that Kayleigh relayed that the tape layout for a Cache-A tape is not one single data set, but rather multiple data sets separated by filemarks. Also, the Cache-A process doesn’t guarantee that the files will be written onto the tape in any specific order, so to have files missing from one data segment would not be a surprise as they would be recovered in the process of extracting another segment.
Here’s a quick test that you can run in a Terminal (assuming BRU PE is installed) –
ERR=0
tapectl rewind
while [ $ERR -eq 0 ]
do
tapectl -v fsf
ERR=$?
tapectl tell
done
You should see multiple block addresses reported and finally a “blank check” error. How many segments are on one of those tapes?Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters! -
I am out of the office now and cannot perform that test until I am back after the holidays.
But isn’t the amount of data sets irrelevant if ArGest IngestPRO was told to ingest all data sets and the software does not do it? It is still unclear if I am doing something wrong when using the software, since the only thing I have control over is identifying the block size. Could a wrong block size cause Argest IngestPRO to miss data sets?
-
That’s what the test will tell us. IngestPRO should have been able to suss out all of the sets on the tape. The layout results that you get from that test will tell us if you have a scenario that we’d not thought of.
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters! -
I have posted a tech brief that details how Cache-A writes tar tapes and how to read them with any tar program here.
Basically, as usual, Tim has it right. Our blocking factor has always been 300. Our writing algorithms generally broke tar sessions into about 90GB depending upon actual file sizes. tar session files were always written in the order the list from the source file system was provided.
I hope that helps.
Tom Goldberg
TGCS
30201 Rainbow Hill Rd.
Evergreen, CO 80439
mailto:tomgoldberg@gmail.com
https://tomgoldberg.net -
Tom,
I was interested in this info too.
But, the link you’ve provided
https://tomgoldberg.net/www/Cache-A/CATechBrief-ReadCAtar.pdf
is a dead link.The correct one is
https://tomgoldberg.net/Cache-A/CATechBrief-ReadCAtar.pdfJust took out the ‘www’ and it worked.
———————————–
Neil Sadwelkar
neilsadwelkar.blogspot.com
twitter: fcpguru
FCP Editor, Edit systems consultant
Mumbai India -
Thanks for the correction Neil – I should test these links before posting!
Tom Goldberg
TGCS
30201 Rainbow Hill Rd.
Evergreen, CO 80439
mailto:tomgoldberg@gmail.com
https://tomgoldberg.net -
Thanks to Mike’s assistance and patience, we’ve uncovered what was causing our ArGest IngestPRO tool to only retrieve every other set on an Cache-A tar tape.
The new version will also properly handle incorrectly formatted LTFS tapes where no volume name was provided or where there was no serial number assigned (we still can’t determine HOW you could create such a badly formatted tape since even the 1.3 code requires both the -n and -s options for formatting a tape on all three platforms).
The 1.0.4 update for ArGest IngestPRO will be available for all users on Thursday.
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.tolisgroup.com
BRU … because it’s the RESTORE that matters!
Reply to this Discussion! Login or Sign Up