Welcome to our community

Be a part of something great, join today!

Log in
  • 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 Guys,

Maybe this is a question for Tim.

I had a whoopsie and had to reload my system during which I lost all the archive catalogue data saved on my system. So now I have to read it from the tapes. I am running Bru LE and I have had no trouble importing archive data using the "Import Tape" button under the Verify tab. I have been restoring tapes fine as well.

However, I have been sailing very close to the wind, I guess, because I have been archiving (and restoring) full 800GB tapes from Bru LE with no problems. At the moment, I am trying to read my archive lists back into the computer. However, I am having a problem with one tape. When I import it appears to be doing everything OK, it reads the archive ident OK, but then just sits there saying it is retrieving the catalogue data. Normally this only takes a minute or so but after half an hour the computer seems to be stuck there so I have to cancel the import. I recall Tim saying in another thread that the actual archive size was not too important, and my experience certainly seems to bear this out, but the total number of files should not exceed 50-75,000. Now on this particular tape my own logs would indicate that it is right up there at the top end of the range (these are all sequential Tiff's from DSLR timelapse). So the question is: Have I exceeded some limit which means that Bru LE can now not read the archive data from the tape; in which case is there anything that I can do about it? Or, does this indicate some form of corruption on the tape itself. The tape was written and verified by my copy of Bru LE and has been stored with my other tapes away from heat, damp, magnetic fields etc.

I have recovered the data in question from a disk backup source but would like to know what this problem is. It would be a bit scary if the media could degrade after only six months or so! If the problem is me then I can fix that!

So any thoughts? Any advice would be much appreciated.

David
 
Jeff Kilgroe said:
@ Maciej,

Yeah, LE is very limited with archive size and requires too much manual intervention and manually splitting up your archives to fill your tapes, especially on LTO.

With BRU PE and BRU Server, there are no such limitations. I use BRU PE and routinely create backups to LTO-4 that are 2 to 4 TB in size and span 3 to 5, sometimes even 6 tapes. No problems.
Click to expand...

Thank you Jeff, that helps a lot.

Now last question. I have a G-speed 8TB es pro raid that comes with a mini SAS raid controller. It seems like the optimal way to feed the HP 1840 data.

Has anyone had experience running a SAS version of that tape drive using the g-tech provided controller.
That means I could skip buying the BRU bundle since the provided ATTO controller would not run the G-tech array in raid mode.
 
HI,
I have a banner up on this site as of a few weeks ago. Anyone who does not have a LTO and needs some backups drop me a line! I use the cache-A prime box. http://www.cache-a.com/products.php

pointblankBANNER.gif

http://thecoloringroom.com/reddailies.html

Also, I found a site for crazy cheap tape here!
http://www.tape4backup.com/lto-4-tapes.php

fuji LTO4 33.00

thanks

jason h
 
Maciej Roszkowski said:
Now last question. I have a G-speed 8TB es pro raid that comes with a mini SAS raid controller. It seems like the optimal way to feed the HP 1840 data.
Click to expand...

Hmmm... Good question. I don't know if it would work or not. Sometimes tape and controller combinations can be a bit finicky under OSX.
 
Jeff Kilgroe said:
Hmmm... Good question. I don't know if it would work or not. Sometimes tape and controller combinations can be a bit finicky under OSX.
Click to expand...
That includes the Areca HBA if my info is correct. It will not work with a tape drive.

BTW - I've updated the general post about HBA compatibility. I'll add a comment to bump it.

Tim
 
Start with a simple CD backup of the catalogs...

Start with a simple CD backup of the catalogs...

This really is a BRU support question and should go through our support team. However, i'll provide a bit of a generic answer here as there are quite a few of you lurking :). One thing that I will mention is that it's a good idea to burn your Archives and Tapes folders (in /private/var/lib/bru) onto CD or DVD media on a regular basis to ease this pain even further.

David Barlow said:
I had a whoopsie and had to reload my system during which I lost all the archive catalogue data saved on my system. So now I have to read it from the tapes. I am running Bru LE and I have had no trouble importing archive data using the "Import Tape" button under the Verify tab. I have been restoring tapes fine as well.
Click to expand...
That is an LE hold-over and did not make the PE cut, so for PE users, that button will be "missing" from the Verify panel. For PE users, please check out my note at the end of this post.

However, I have been sailing very close to the wind, I guess, because I have been archiving (and restoring) full 800GB tapes from Bru LE with no problems. At the moment, I am trying to read my archive lists back into the computer. However, I am having a problem with one tape. When I import it appears to be doing everything OK, it reads the archive ident OK, but then just sits there saying it is retrieving the catalogue data. Normally this only takes a minute or so but after half an hour the computer seems to be stuck there so I have to cancel the import. I recall Tim saying in another thread that the actual archive size was not too important, and my experience certainly seems to bear this out, but the total number of files should not exceed 50-75,000. Now on this particular tape my own logs would indicate that it is right up there at the top end of the range (these are all sequential Tiff's from DSLR timelapse). So the question is: Have I exceeded some limit which means that Bru LE can now not read the archive data from the tape; in which case is there anything that I can do about it? Or, does this indicate some form of corruption on the tape itself. The tape was written and verified by my copy of Bru LE and has been stored with my other tapes away from heat, damp, magnetic fields etc.
Click to expand...
You've not hit a limit for recovery of the archive catalog and you are correct that the number of files in a given archive is the main issue when working with BRU LE (thus the name "Light Edition"). In this case something's not right there if the catalog is not being restored in short order (as your other imports have demonstrated). Is it possible that you are working from a multi-tape set? If so, you really only need to insert the last tape of the set to recover the catalog. We have had reports of LE getting confused if the archives are very large and cross multiple tapes (i.e.1TB+)

One of my team's film buffs says it's because you're using a DSLR for film work. :001_tongue:

I have recovered the data in question from a disk backup source but would like to know what this problem is. It would be a bit scary if the media could degrade after only six months or so! If the problem is me then I can fix that!
Click to expand...
My suspicion is that the tape is not ordered properly and I seriously doubt that you're suffering from degraded media. If you'd like to track this further, send me a PM and I'll be glad to take a look at the tape to see exactly what occurred. We can share the results with the list.

Now for the PE announcement

If you're using PE, you will have noticed that the 2.0.x version doesn't offer the Import function that David mentioned in the notes above. We were originally working to incorporate an import function within the PE interface when a prominent user asked if it could be a standalone tool. With that we actually realized that the functionality could be better served in a standalone tool rather than stuffed into the main UI. I'm very happy to announce that the first BETA of the BRU Import Tool is ready for abuse.

While the tool is a standalone tool, it does require a licensed copy of BRU PE on the system where it is run. Also, it is NOT compatible with BRU LE or Server, but it will import LE and Server (and even BRU Unix) tapes for restore purposes in BRU PE.

With this tool, you can transfer physical tapes between sites and each site can easily import the tapes so that they have the same information as the system where the tapes were created. This is good for multiple storage locations, sending Doubled media to clients or offsite storage.

When it's released, the BRU Import Tool is free to registered PE users. Also, it is not dependent on any specific version of BRU PE, so you don't need to wait for PE 2.1.0 to use it.

If you're interested in BETA testing the tool, please send me a PM and I'll send more details.

Tim
 
Hi Tim,

Glad to see you back.

You've not hit a limit for recovery of the archive catalog and you are correct that the number of files in a given archive is the main issue when working with BRU LE (thus the name "Light Edition"). In this case something's not right there if the catalog is not being restored in short order (as your other imports have demonstrated). Is it possible that you are working from a multi-tape set? If so, you really only need to insert the last tape of the set to recover the catalog. We have had reports of LE getting confused if the archives are very large and cross multiple tapes (i.e.1TB+)
Click to expand...

The tape is definitely not part of a multi-tape archive. I have only created 20 archive tapes so far and this was the only one that I was unable to read in again. Having said that, when I put the tape in the drive and press import, Bru says that it recognises the tape and asks if I wish to rescan it. It reads all the correct archive and catalogue ID's and scans the tape for archive's. It then gives the message, retrieving catalogue data and hangs there. This part normally takes a second or two with all the other tapes. However, no archive appears in my archive list and I eventually have to cancel the import.

The amount of data involved is 639.61GB made up of 73,987 individual Tiff files plus presumably a few invisible or other files. Another tape I have consists of 72,783 Tiff's totalling 637.76GB which writes as 728.53GB on the tape. This tape catalogue was imported and the data restored into the computer fine. As have all the others.

I have not lost the data and can make a new tape. However, it would be nice to know what might have caused this as one day it might be my only copy. Is it possible that some terminating expression did not get written at to close the catalogue entry because of the size of the archive? I do verify all the tapes.

I guess that your advice is going to be to archive off this kind of data in smaller chunks in future! Thanks for the info about where the catalogue files are kept, I will definitely back them up. Sad thing is that they were backed up but once the new install appeared to be working OK, I only kept the users folder and deleted all the system data from the backup in favour of the new installation! Then I tried to make a backup tape and no catalogue!!

R3D's and Quicktime's are a lot easier to deal with.

One of my team's film buffs says it's because you're using a DSLR for film work.
Click to expand...

You can blame Tom Lowe! Once I saw his stuff I thought I have got to have a go at that! Not in his league though. :laugh:

David
 
Just another thought. If this were to happen in a vital situation, is there any way to recover the data on the tape? Or if the catalogue is damaged is that it. Kaput!! scary thought.
 
BRU To The Rescue

BRU To The Rescue

David Barlow said:
Just another thought. If this were to happen in a vital situation, is there any way to recover the data on the tape? Or if the catalogue is damaged is that it. Kaput!! scary thought.
Click to expand...
The data's absolutely not lost! Unlike other backup tools, the loss of a catalog is just the loss of a nicety feature. You can always take the tape and BRU down to the command line and restore everything there regardless of the existence of the LE catalog.

If you need help restoring in such a situation, our support team will provide guidance if the command line environment is not your bag.

Here's a quick example to verify a tape from the command line:

bru -ivvvvvf ntape0​

That tells BRU to "inspect" the tape and provide level 5 verbosity (-v to -vvvvv) as output. During the inspection, BRU recalculates the 32bit CRC for every 2K of data that you wrote to the tape and compares the newly calculated value against the value written into the block headers on the tape. We don't even need to be on the same system (or even the same OS) where the archive was created.

The output looks like this (From a DAT 320):
Code: 
$ bru -ivvvvvf ntape0 -b 1M
**** archive header info ****
label:		Archive of AC_DC
created:	Tue Feb 16 15:47:05 2010
artime:		1266360425
archive_id:	4b7b20693a9e
volume:		1
writes:		0
release:	17.1
variant:	0
bufsize:	1048576
msize:		0
msize_blks:	0
serial_number:	UNSERIALIZED
device:		ntape0
user:		root
group:		wheel
system:		Darwin macpro.t 10.2.0 Darwin K i386
bru:		mac-osx
command_line:	bru -calmvvvvvvvvvjf ntape0 -L Archive of AC_DC -
**** end info ****
archive ID = 4b7b20693a9e
label = Archive of AC_DC
buffer size = 1024k bytes
media size = <unknown>
i 1024K [1] drwxrwxr-t 36 root     admin             0 Jan 26 14:46     2 /
i 1024K [1] drwxrwxrwt 11 root     admin             0 Feb 16 15:14 26120 /Volumes
i 1024K [1] drwxrwxr-x 14 tjones   staff             0 Feb  8  8:37     2 /Volumes/Part 2
i 1024K [1] drwxr-xr-x 393 tjones   staff             0 Feb  8 13:16 64374 /Volumes/Part 2/Music
i 1024K [1] drwxr-xr-x  4 tjones   staff             0 Jan 21  7:09 84671 /Volumes/Part 2/Music/AC_DC
i 1024K [1] drwxr-xr-x 12 tjones   staff             0 Jan 21  7:09 84673 /Volumes/Part 2/Music/AC_DC/Back In Black
i 1024K [1] -rw-r--r--  1 tjones   staff      10657697 Jan 21  7:09 84674 /Volumes/Part 2/Music/AC_DC/Back In Black/01 Hells Bells.mp3
i 12288K [1] -rw-r--r--  1 tjones   staff      10866864 Jan 21  7:09 84675 /Volumes/Part 2/Music/AC_DC/Back In Black/02 Shoot To Thrill.mp3
i 24576K [1] -rw-r--r--  1 tjones   staff       7406842 Jan 21  7:09 84676 /Volumes/Part 2/Music/AC_DC/Back In Black/03 What Do You Do For Money Honey.mp3
i 32768K [1] -rw-r--r--  1 tjones   staff       7198169 Jan 21  7:09 84677 /Volumes/Part 2/Music/AC_DC/Back In Black/04 Givin' The Dog A Bone.mp3
i 40960K [1] -rw-r--r--  1 tjones   staff       8719094 Jan 21  7:09 84678 /Volumes/Part 2/Music/AC_DC/Back In Black/05 Let Me Put My Love Into You.mp3
i 50176K [1] -rw-r--r--  1 tjones   staff       8728899 Jan 21  7:09 84679 /Volumes/Part 2/Music/AC_DC/Back In Black/06 Back In Black.mp3
i 60416K [1] -rw-r--r--  1 tjones   staff       7218963 Jan 21  7:09 84680 /Volumes/Part 2/Music/AC_DC/Back In Black/07 You Shook Me All Night Long.mp3
i 68608K [1] -rw-r--r--  1 tjones   staff       8139932 Jan 21  7:09 84681 /Volumes/Part 2/Music/AC_DC/Back In Black/08 Have A Drink On Me.mp3
i 77824K [1] -rw-r--r--  1 tjones   staff       8443553 Jan 21  7:09 84682 /Volumes/Part 2/Music/AC_DC/Back In Black/09 Shake A Leg.mp3
i 87040K [1] -rw-r--r--  1 tjones   staff       8804384 Jan 21  7:09 84683 /Volumes/Part 2/Music/AC_DC/Back In Black/10 Rock And Roll Ain't Noise Pollution.mp3
i 96256K [1] drwxr-xr-x 14 tjones   staff             0 Jan 21  7:09 84684 /Volumes/Part 2/Music/AC_DC/Stiff Upper Lip
i 96256K [1] -rw-r--r--  1 tjones   staff       8198105 Jan 21  7:09 84685 /Volumes/Part 2/Music/AC_DC/Stiff Upper Lip/01 Stiff Upper Lip.mp3
i 105472K [1] -rw-r--r--  1 tjones   staff       8484187 Jan 21  7:09 84686 /Volumes/Part 2/Music/AC_DC/Stiff Upper Lip/02 Meltdown.mp3
i 115712K [1] -rw-r--r--  1 tjones   staff       9050421 Jan 21  7:09 84687 /Volumes/Part 2/Music/AC_DC/Stiff Upper Lip/03 House Of Jazz.mp3
i 125952K [1] -rw-r--r--  1 tjones   staff       9144778 Jan 21  7:09 84688 /Volumes/Part 2/Music/AC_DC/Stiff Upper Lip/04 Hold Me Back.mp3
i 136192K [1] -rw-r--r--  1 tjones   staff       9126599 Jan 21  7:09 84689 /Volumes/Part 2/Music/AC_DC/Stiff Upper Lip/05 Safe In New York City.mp3
i 145408K [1] -rw-r--r--  1 tjones   staff       8504039 Jan 21  7:09 84690 /Volumes/Part 2/Music/AC_DC/Stiff Upper Lip/06 Can't Stand Still.mp3
i 155648K [1] -rw-r--r--  1 tjones   staff       9052304 Jan 21  7:09 84691 /Volumes/Part 2/Music/AC_DC/Stiff Upper Lip/07 Can't Stop Rock 'N' Roll.mp3
i 165888K [1] -rw-r--r--  1 tjones   staff       8568421 Jan 21  7:09 84692 /Volumes/Part 2/Music/AC_DC/Stiff Upper Lip/08 Satellite Blues.mp3
i 175104K [1] -rw-r--r--  1 tjones   staff       8750248 Jan 21  7:09 84693 /Volumes/Part 2/Music/AC_DC/Stiff Upper Lip/09 Damned.mp3
i 184320K [1] -rw-r--r--  1 tjones   staff       9245594 Jan 21  7:09 84694 /Volumes/Part 2/Music/AC_DC/Stiff Upper Lip/10 Come And Get It.mp3
i 195584K [1] -rw-r--r--  1 tjones   staff      10253978 Jan 21  7:09 84695 /Volumes/Part 2/Music/AC_DC/Stiff Upper Lip/11 All Screwed Up.mp3
i 206848K [1] -rw-r--r--  1 tjones   staff       8758985 Jan 21  7:09 84696 /Volumes/Part 2/Music/AC_DC/Stiff Upper Lip/12 Give It Up.mp3
bru: [I181] read 108032 blocks (216064 KBytes) on volume [1], 0:00:28, 7716 KB/sec 

**** bru: execution summary ****

Started:		Wed Feb 24 08:51:17 2010
Completed:		Wed Feb 24 08:51:45 2010
Archive id:		4b7b20693a9e
Messages:		0 warnings,  0 errors
Archive I/O:		0 blocks (0KB) written
Archive I/O:		108032 blocks (216064KB) read
Files written:		0 files (0 regular, 0 other)
Files read:		29 files (22 regular, 7 other)
Files skipped:		0 files
Volumes used:		1
Write errors:		0 soft,  0 hard
Read errors:		0 soft,  0 hard
Checksum errors:	0

Feel a bit more secure now? :beer:
 
Thank you Tim. Yes I do feel more secure. I really think Bru LE is a useful little app for the likes of me. Relatively simple to use but provides everything needed for a one-man-band to backup and archive R3D and movie files. Please do not remove the "Import" button!! Very useful.

I am not computer savvy so I find command line stuff a bit opaque. However, I have rootled around there on occasion when given some instructions so between the manual and your support team I could probably recover my data if necessary. So once again, thank you for the advice.

David
 
Tim Jones said:
That includes the Areca HBA if my info is correct. It will not work with a tape drive.

BTW - I've updated the general post about HBA compatibility. I'll add a comment to bump it.

Tim
Click to expand...

Based on that statement am I safe to assume that the G-Tech card is an Areca HBA ? Under Mac OS it reported as a G-Tech card so i couldn't see the manufacturer. There goes that dream.
 
Maciej Roszkowski said:
Based on that statement am I safe to assume that the G-Tech card is an Areca HBA ? Under Mac OS it reported as a G-Tech card so i couldn't see the manufacturer. There goes that dream.
Click to expand...
Unfortunately, I believe that it is. I have one other report that the G-Tech card has the same limitations as the Areca. And since their focus is also on Disk I/O, tape is not something they would be promoting as compatible either way.

Sorry,
Tim
 
Tim Jones said:
Unfortunately, I believe that it is. I have one other report that the G-Tech card has the same limitations as the Areca. And since their focus is also on Disk I/O, tape is not something they would be promoting as compatible either way.

Sorry,
Tim
Click to expand...

Thank you. I guess I will focus on the ATTO card.
 
All new Question

All new Question

Right now working with my Quantum LTO 3

I been using LE so far and I am testing the PE software.

Having an off issues where the tape drive writes my archive (estimated at 274 GIG), does a verify and than is stuck and an overlay window that says "The current Tape has been verified. Insert next tape to continue". I tried inserting a blank tape to see if that is what it was asking for in case it did a write and verify on a partial archive. But it just spits it back out and brings the message back. Seem like the only way to get out now is a force quit. I tried this a few times today and it repeats.
 
Just a quick one to say that we bought Bru Server and found it very difficult to use.
A lot of issues with setup, and operation. We basically ditched it.

Now trying Archiware's Presstore, and finding it much easier to use.
With Bru, you have to go through a whole routine to get the tape drive working at a good speed for the drive. This involves running Unix routines and a world of pain.

Presstore worked straight out of the box and gave us 65 mb/s without any issues....

Plus I think Tolis doesn't have any UK support....
 
Any idea when we should expect the release of BRU PE 3?
 
Tim,
I have a quick question about how BRU selectively restores files off a tape:

Let's say you want to restore two files from a single archive, and despite being in the same archive there is some distance between them on the tape. It seems as if BRU will seek to the location of the first file and begin to restore, but from that point on it will have to read the entire archive at normal restore speed until it comes across the next file to restore - instead of being able to quickly shuttle forward to the next file's position. Is this a limitation of the software/drive architecture?

Thanks!
 
AMT said:
Tim,
I have a quick question about how BRU selectively restores files off a tape:

Let's say you want to restore two files from a single archive, and despite being in the same archive there is some distance between them on the tape. It seems as if BRU will seek to the location of the first file and begin to restore, but from that point on it will have to read the entire archive at normal restore speed until it comes across the next file to restore - instead of being able to quickly shuttle forward to the next file's position. Is this a limitation of the software/drive architecture?

Thanks!
Click to expand...

I recall running into a similar problem in BRU PE, maybe it is a bug? I tried to restore some non-sequential data and it started off fine, but then had problems finding the next file/folder I had chosen. Maybe it was just slow, I was impatient and canceled the operation.
 
You must log in or register to reply here.
Back
Top