Craigo5000

Personally, I'd not use thorough verification. Instead, use MD5 checksum. Much quicker. (Media Verification which eliminates re-read of LTO media)

So I see v12 offers this with a small paragraph stating Avid project support? There isn't really any further details on what it does though? Can someone enlighten me as I look after 10 Avid suites in a post production environment and the ability to archive in LTFS also sounds great!

So if I go to the Disk backup sets properties/options and select "Groom to remove backups older than 7" this would allow me a week of nightly Disk to Disk backups before a scheduled weekly Sunday LTO archive backup of all of that data? Bear in mind, the LTO archive should chronologically grow and contain EVERYTHING and the DAS should stay under a threshold size.

*update* I've since had my shared storage LTO backup waste tapes on two occasions now. At around the 400GB and 600GB mark of 2.5TB tapes. I recatalogued off the previous last tape in the set and wiped the wasted tape so it could be used for something else. Since then, I've decided to give Disk-Disk-Tape a go as a method to stop this tape wastage. here is my workflow: Data to be backed up - 2.5TB NAS shared to all clients for general use. I've hooked up a new 40TB fiber DAS which is also available on the ethernet network. I've created a folder on here for the 2.5 TB NAS share to be backed up by Retrospect on a nightly bases (with a 3TB capacity). The LTO backup process then backs up from the DAS Retrospect backup. The DAS backup is all obviously in propriety language but I can search the DAS backup nicely via Retrospect and restore anything required. The problem is, this archive will just grow and grow. How do i cull it, but know that I have EVERYTHING on the LTO archive? Thanks

Both good points. I did check all firmware. I actually updated the IBM LTO6 drive firmware and autoloader to their latest and greatest before putting this into service. They were both shipped to me one revision out of date. After spending some time rebuilding the catalogue as mentioned earlier, a few days passed by and the loader complained that the drive needed a clean. I ran a cleaning tape through it and it's been fine ever since. I can only conclude from the error console that the "trouble writing" was referring to dirt/dust on the tape head? (which is brand new) Thanks

Hmm. Not quite. I came in this morning to find the scheduled backup set has only used 500GB on tape 3 (of 2.5TB available) and then picked another member to add to the backup set where the rest of the 25GB was allocated in order to complete the scheduled backup. Here's the log: - 20/11/2015 01:00:00: Copying Productions on assets 20/11/2015 01:02:21: Found: 32,121 files, 4,617 folders, 2,300.0 GB 20/11/2015 01:02:22: Finished matching 20/11/2015 01:02:22: Copying: 158 files (523.6 GB) and 0 hard links E-mail notification failed: error -507 (incorrect password) Trouble writing: "3-ProductionAssets 2015" (3899326464), error -100 (device rejected command) - 20/11/2015 04:01:33: Verifying Productions on assets Trouble writing media: "3-ProductionAssets 2015" error -100 (device rejected command) - 20/11/2015 05:01:31: Copying Productions on assets 20/11/2015 05:09:19: Building Snapshot... 20/11/2015 05:09:21: Copying Snapshot: 1 files (8,513 KB) 20/11/2015 05:09:25: Snapshot stored, 8,513 KB 20/11/2015 05:09:25: 1 execution errors Completed: 158 files, 523.6 GB Performance: 2907.2 MB/minute Duration: 03:13:33 (00:09:07 idle/loading/preparing) - 20/11/2015 05:09:25: Verifying ProductionAssets 2015 20/11/2015 05:13:19: Execution completed successfully Completed: 158 files, 523.6 GB Performance: 9133.7 MB/minute Duration: 00:59:45 (00:01:02 idle/loading/preparing)

Just updating to this with success on the RBC rebuild from the latest member. The rescanning of Tape 2 took about 3 hours and then left me with a redefined backup set with only the two associated members. Hopefully with my refined security backup settings, I shouldn't get any further huge duplication and have to repeat the above process. Thanks for the help Lennart and Scillonion.

Ahh. I knew about that, but assumed since I'd effectively erased Tape 4 and set the backup set member to "missing", the fast-build facility would no longer function. I didn't realise it worked in that manner. That's good.

Thanks Lennart, I've chosen option 2. Having "forgot" tapes 3 and 4, Retrospect prompted me to select the last tape in the set, tape 2. I made a copy of the original .rbc catalog and moved it somewhere safe as Retrospect wanted to overwrite the existing .rbc. Will it not want to also rebuild the catalog using tape 1 too? I need to ensure this rebuilt .rbc references all media in the backup set. Thanks

How would one ensure SCSI errors never happen? This is a brand new autoloader and tape drive running on a vanilla version of Windows 7 on a very capable HP Z600 far exceeding the minimum system requirements. Sorry to pester - I just need this to work reliably asap.

Thanks for the link. I guess it's something to consider... Out of interest, I'm in limbo now with this backup set. It contains 4 tape members and tapes 3 and 4 I know I can erase and set them to "forget" as the media is definitely duplicate media that exists on tapes 1 and 2. How would one go about completely removing the members tapes 3 and 4 from the backup set so that on the next scheduled run, it picks an erased tape and automatically calls it tape 3 and not tape 5? I can't rebuild the backup set as I need two LTO6 drives to perform this task. Will a catalog repair do this job? Thanks

Cross posting sorry! When creating a new tape backup set at the naming stage there is an option only available when "tape" is chosen which allows you to toggle on/off "allow hardware data compression". The reason I did this is because LTO6 is native 2.5TB uncompressed and I ran a speed test for a day over the same backup data with and without hardware data compression. Turning it off displayed an backup speed increase of around 30% which is more desirable than the compression feature. (Where already compressed files don't re-compress very well). In 2015, post production budgets are shrunk beyond those of the early 90's. If I allow this backup set to continually waste available media (using 500GB of 2.5TB available!) on a tape then I get it in the neck from my Finance Director when I need to unnecessarily make another bulk order for 50 x LTO6 tapes (@ £1250). I need to get this figured out.

I've added those settings changes. Also, I've analysed the log and can see the following error code at the point where the current tape was swapped by the loader with a partial backup: Trouble writing media: "3-ProductionAssets 2015" error -100 (device rejected command) Looking this up, it appears "file sharing" could be an issue or SCSI termination? The LTO6/autoloader drive is SAS connected.

Thanks, I'll give that a try and report back. I've come in this morning to find that one of the shared NAS folders which is scheduled for nightly backups has wasted 2 x LTO6 tapes. It's added two of them as members to the backup set and only used 515.8GB on tape 3 and is at 240.7GB for tape 4. I've configured backup sets to not use hardware or software compression. I'd really like to be confident in using at least 2TB per tape or else this is a very expensive way of backing up when it's £25 per tape!

Hi Lennart, The sources are varied but are always network shares. I've witnessed this on backup sets belonging to ethernet network attached storage systems (aggregated links so network transfer speeds of around 100Mb/s). Other sources are fibre attached storage arrays capable of 4GB/s. I understand LTO is capable of very fast spool speeds and will slow down or even stop in some instances during a backup before then restarting. I still don't understand when I preview my next scheduled backup, it wants to back up 749GB of old media already contained within the existing backup set of which is also searchable via the catalog for restore? Thanks