Hi

Well, the subject says it all. I know what JBOD is, in theory. Everybody seems to know, BUT: Who is using it currently? Does anybody really know how to set it up in Linux?
Is JBOD actually anything at all, except describing that you have drive a, drive b and drive c hanging on a SATA bus?

I have the following problem: I got a 2 TByte RAID array, which I want to backup, using 2 disks, 1 TB each. Now I don't want to use striping obviously (raid 0) since the risk of losing either one of the disks doubles my risk for losing the whole backup.
JBOD, "glueing" two drives together and use them as one 2 TB drive would be my idea. If either one of the drives fails, at least I got half the backup remaining.

My backup program of course does not allow spanning over two disks (backintime (a thing based on rsync)). Is there another way to to achieve this? To appear to the OS like it is one big drive, while having both drives independent of eachother?

I have googled around and nobody seems to really know what the heck JBOD REALLY is.

Cheers

Markus

I was always under the impression that JBOD was a collection of drives connected to a controller and the controller publishing each drive as a separate entity.

As to how to backup your 2TB to 2x 1TB drives, look at dar

Dar looks good, but unfortunately, it does not do what backintime does sooo cleverly: create a rsync backup and then manage the differentials by means of links, pretty clever (in case you were not familiar with it)

I need a transparent layer that I can shove in between.
So JBOD means actually nothing at all. So you just say disks, several disks, my harddisks, any disk(s). No need for a special term for something that is already there and actually means nothing new.
It is like I call the sun blarmsn, just because to invent a new word for the word sun, that already exists. ;-)

I think a lot of people are under the impression that JBOD offers a raid kind like functionality to bunch together two or more disks and make it seem to the OS to be one big device, without the horrendous risk of dataloss that RAID 0 has.

So, for all of you reading this: No, it is not.

But thanks for the Dar thing.

Markus

http://en.wikipedia.org/wiki/JBOD#JBOD

pretty much what phil.d.b said. Typically a box that is sold as a unit which contains a bunch of drives and doesn't have a lot of overhead or hardware raid. Attached to your server, it appears as just a bunch of drives.

I have a Sun J4200 on one of my servers. It has dual SAS controllers, my server has similar, and it is configured with SAS multipathing. Then I use zfs to put it all together into a raidz2. It has 12 drives.

On another server, I have a StorageTek 2510. It also has 12 drives, but has all kinds of complication, hardware raid, a separate service processor, etc. I ended up making it present each drive as an individual target without doing any hardware raid. Then, just like the J4200, I used zfs on the server to configure it. That was much more of a pain.

Your second paragraph about "JBOD gluing" makes no sense. Any kind of glue is either hardware or software striping or raid, either in the box or on the server.

Yes, but the glue I need is neither RAID nor striping. Striping makes both drives fail if one does. Not acceptable.
And any other raid involves more than two drives, and furthermore does not offer full capacity of all drives involved.
The scheme I need surely is possible and feasible. Kind of like a tape thing: fill up one HD, then when full, fill up the second one. If one breaks, you got exactly half the data (given of course that both drives are full).

I frankly never saw the point of RAID 0, because the more drives it involves, the higher the risk gets of losing one drive and hence, losing the whole array. And which data do you care saving in the first place when you are putting it at such risk of losing it?

I will look into LVM, that might be maybe something. I remember reading something once about that you could extract data still even if a LVM set is broken (so it does not seem to stripe it).

So the basic issue with your backups is that you want to cram an elephant into a shoe box and figure there ought to be a way of fitting the extra parts into a second shoe box.

Unfortunately, when the thing you want to back up gets bigger than the thing you want to use to back it up to, you have a fundamental problem. You need elbow room and capacity to do backups. If you segment the backup, and lose one of the segments, you are losing backups of some of your original. If you can logically break the original into two pieces (a few directories here and a few more there), then you might be able to backup each piece to one of your other drives.

The alternative is to get more backup capacity. While tapes have an advantage that some backup software can span tapes, the loss of one of those tapes causes serious problems with that instance of the backup. But, the other advantage is redundancy. Typically, people who use tapes have multiple full and incremental backups over a span of weeks or months. If they lose one tape, they probably are covered by multiple others.

Multiple terrabytes of data are inherently problematic. To back that data up, you need comparable backup storage at the least. For redundancy, you need more. If you only have one backup, then you have to pay more attention to possible failures. As soon as you have a failure of either the original or the backup, you are at risk (an additional failure will lead to loss of data), and you have to take action to reduce the risk right away.

I think in your case you need additional drives to set up a raid for backup, or you should stripe the two you have and figure that it's a backup, so, if it fails, you have to quickly fix it to make sure you still have a backup. One way out would be if your data is sufficiently compressible. But, if you are dealing with media files, many of those are already compressed.