Tim Jones
Forum Replies Created
-
All of the manufacturers are at the same level of reliability from a hardware standpoint, but the vendors have varying levels of support depending on your platform.
If you’re Windows, you’ll be okay with all of the majors – HP, IBM, Tandberg Data, Quantum (TOLIS Group after NAB)
If you’re Mac, we recommend HP or our (TOLIS Group) versions of the HP solutions simply because we know how to support you on the Mac platform while IBM, Quantum and Tandberg are known to point fingers because they don’t know how to support the Mac platforms.The only aside I’ll make is to use only HP or Fujifilm branded tapes regardless of the actual tape drive you end up purchasing.
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.productionbackup.com
BRU … because it’s the RESTORE that matters! -
Hi Eric,
Your proposed workflow is dead on. That’s why we classify the tapes in a library by destination definitions rather than just grabbing slots. Also, by specifying destinations, you can limit a job’s access to tapes in other slots – BRU will prompt you for more tapes if you fill a destination rather than just moving to other slots.
As for restoring from a standalone drive, this is also possible and in fact BRU PE is designed to work that way. If you look at the setup panel for a restore job, you can see that you can select the library or a separate standalone drive from the source popup menu. BRU PE will prompt your operator for each tape as required.
HTH,
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.productionbackup.com
BRU … because it’s the RESTORE that matters! -
Ask yourself these questions –
- How much did it actually cost to create the original media?
- How much was my time worth to create the original media?
- How much would it cost me to recreate the project from scratch?
Based on your honest answers, consider these costs to archive the work:
- A 2TB consumer-grade disk costs around $99
- A 2TB enterprise-grade disk costs around $160
- If you have an LTO-5 or LTO-6 tape drive, a 1.5TB LTO-5 tape costs around $30, 2.5TB LTO-6 around $70
Do the numbers balance (i.e.: is the disk or tape more cost effective than recreating the work)?
I recommend that you save everything – from originals through to rendered finals – unless you KNOW that it’s a one shot job and you’ll never need to revisit the subject (not just the job). You never know when today’s cast off clips might become a money and time saving b-roll in tomorrow’s project.
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.productionbackup.com
BRU … because it’s the RESTORE that matters! -
[TG] – …but I would never bother using that script for cloning LTFS or Cache-A tar tapes as we have a perfectly good user interface that does that for you.
Except that script was simply an example of how you at Cache-A could implement such an interface to perform the cloning. The type of UI that you expose to the end user is totally up to you, so please don’t imply that using a script is a bad thing. I’m sure that under the hood, the Cache-A platform uses a plethora of scripts to accomplish what you do.
Also, the magic numbers that you mention are YOUR choices – also the 300 number for a Cache-A tar tape is actually 300 tar blocks or 150KiB and the LTFS 512 number is 512KiB. These are important details. Also, both tar and LTFS can use other block sizes depending on who makes the tapes. And, as we found out with BRU – described below – those Cache-A defaults may provide the most efficient I/O for one type of data, but definitely not for others.
The BRU block size varies depending on the user’s data needs and archival device type. We learned long ago that I/O block sizes were not a one size fits all number. You may have tapes that are written at 32k aimed at business data (emails, documents) where files are measured in kilobytes or small megabytes, database backups where block sizes ranging from 64k to 512k are fastest, and finally media where block sizes of 1MB, 2MB, or up to 16MB are the most efficient.
However, unlike LTFS, TAR, and CPIO, BRU archives contain the block size information in the archive header and BRU can be given this information readily using our tapectl tool on OS X and Windows and the system log tools on other Unix/Linux platforms. This is just one more implementation detail that allows BRU archives to be TRULY cross platform with no prior knowledge of the environment where an archive was created.
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.productionbackup.com
BRU … because it’s the RESTORE that matters! -
In that case, the same logic could be applied to cloning BRU tapes, or CPIO tapes, or Retrospect Tapes, or MTF tapes (CA, Symantec, etc.) …
#!/bin/sh
# Free and Open Source script to copy tapes between 2 drives
# written by probably hundreds of Unix system operators over the past 30 yearsEOFDETECTED=0
mt -f /dev/nst0 stopt scsi2log can-bsr async
mt -f /dev/nst1 stopt scsi2log can-bsr async
while [ ! EOFDETECTED ]
dodd if=/dev/nst0 of=/dev/nst1 bs=TAPEBLOCKSIZE conv=sync
EOFDETECTED=$?done
Of course, for LTFS or CA tapes, you need to remember to check for multiple partitions and partition the destination tape properly.
Works every time so long as you know what block size the tape was created using and that you’ve mapped out the filemarks so that you know how many times to run the operation to get all of the sets on the tape (although that while loop gets it almost every time).
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.productionbackup.com
BRU … because it’s the RESTORE that matters! -
Tom is correct in that the Cache-A devices are not able to clone a BRU tape (or any other tape format, for that matter), but copying a tape is not specific to the format of the data written if the tools required are included in the host OS. This is where the Cache-A limitation occurs, not in the fact that the tape was written in BRU format (so please ignore that attempt at playing the proprietary card here).
If the Cache-A host environment included raw tape access capabilities, it could easily be used to duplicate a BRU (or any other tape) so long as 2 similar tape drives were attached.
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.productionbackup.com
BRU … because it’s the RESTORE that matters! -
Another option would be to use the “diff” utility:
Mount the camera card as before
copy the clips to the new folder
diff -q /Volumes/CameraCard /Volumes/Array/NewFolder
that will only print the names of the files that differ.Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.productionbackup.com
BRU … because it’s the RESTORE that matters! -
It appears that the only way to get this to do what Seth is looking for is to use ‘shasum’ to create a checksum list for the original media folder, copy that file into the destination folder after the copy, and then run the ‘shasum -c’ option to compare those sums against the files in the copy folder.
mount the card (/Volumes/CanonCard for this example)
cd ino the mount point
find . -type f -exec shasum {} >> checksums.sha \;
copy the clips to the new location
copy the checksums.sha file to that same folder
cd into the new folder
shasum -c checksums.sha | grep -v “OK$”That should only print out the files that don’t match.
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.productionbackup.com
BRU … because it’s the RESTORE that matters! -
Simple answer, Nope. But, that’s not due to any issue with the BRU format on tape, just that the Cache-A unit doesn’t offer that type of functionality without Cache-A making changes and including a raw-copy function.
However, you can use the “tapecopy” tool included in BRU PE to create copies so long as you have two non-Cache-A tape drives.
Tim
—
Tim Jones
CTO – TOLIS Group, Inc.
https://www.productionbackup.com
BRU … because it’s the RESTORE that matters! -
md5 theClipFolder
Retraction – I just discovered that the OS X md5 utility won’t operate on a folder…