External backup SATA box config recommendations

[SwisherSweet]

Hi,

I'm setting up my backup. Have a Mac Pro with 7 x 3TB drives in RAIDZ2.

I have 2 x 5-drive eSATA enclosures filled with 2 TB drives (10 drives total).

There are numerous configs I can make with the externals, including 1 or 2 pools, RAIDZ1/2/3.

I would like to have 100% or more space in backups so I can use the rsync time machine script and keep historical changes.

On a side note, an ancillary goal is to migrate the drives I remove from the Mac Pro to the external units as I need more space and replace with higher capacity drives.

Does any have any recommendations in the external drive configs to maximize backup storage and data safety?

 

[SwisherSweet]

My biggest concern is that one of the eSATA enclosures will fail, so perhaps it would be safest to setup 2 vdevs - one per each enclosure. This will give me the added benefit of being able to increase capacity independently of the other enclosure.

Is RAIDZ1 good enough for a 5-drive 2TB drive enclosure used for backup?

 

[zoomzoom]

eSATA cases should never be used as main pools... backup pools that are backed up to once a week or every other week, sure, but not main pools. eSATA cables are the most finnicky of all interface cables, as it takes next to nothing for the cable to cause data corruption.

• Quality eSATA cables are few and far in between, with even MonoPrice's eSATA cables consistently failing after a relatively short period of time. The only eSATA cables I've yet to have corruption caused by are the cables that came with my two SilverStone TS431's, however I've only been using them as backup pools for ~4 weeks (MonoPrice's would last for 12 - 18 months before they'd randomly begin causing data corruption).
  • To provide an example, I used to use a single drive eSATA enclosure for an 8TB Surveillance HDD I use with DirecTV as my DVR drive, and I went through 6 eSATA cables over three years due to each eventually causing data corruption while recording. I got sick of warranting cable after cable, so I opened the HR54, removed the stock 1TB drive and installed the 8TB in it's place... not a single issue since.

 

[Stux]

Sounds like the sensible thing is to have both be their own pool/vdev.

At least you could scrub the data then

I'd probably go raidz1 in this scenario, after all it's just a backup...

 

[SwisherSweet]

eSATA cases should never be used as main pools... backup pools that are backed up to once a week or every other week, sure, but not main pools. eSATA cables are the most finnicky of all interface cables, as it takes next to nothing for the cable to cause data corruption.

• Quality eSATA cables are few and far in between, with even MonoPrice's eSATA cables consistently failing after a relatively short period of time. The only eSATA cables I've yet to have corruption caused by are the cables that came with my two SilverStone TS431's, however I've only been using them as backup pools for ~4 weeks (MonoPrice's would last for 12 - 18 months before they'd randomly begin causing data corruption).
  • To provide an example, I used to use a single drive eSATA enclosure for an 8TB Surveillance HDD I use with DirecTV as my DVR drive, and I went through 6 eSATA cables over three years due to each eventually causing data corruption while recording. I got sick of warranting cable after cable, so I opened the HR54, removed the stock 1TB drive and installed the 8TB in it's place... not a single issue since.

Makes sense. I will only be using these as backups.

I presume a failed backup device won't affect my main data pool.

 

[SwisherSweet]

Sounds like the sensible thing is to have both be their own pool/vdev.

At least you could scrub the data then

I'd probably go raidz1 in this scenario, after all it's just a backup...

Thanks. I beleive this is the path I'm going to go. :)

 

[zoomzoom]

@SwisherSweet Not all. Just be extraordinarily cautious if you need to access anywhere around the eSATA cable(s). Ideally, if you ever need to access the general vicinity of the eSATA cable(s), I would recommend simply exporting the pool, then importing it back in as soon as you've done what you need to do.

IIRC, if a pool is off-lined mid i/o (say due to the eSATA cable), it will cause pool corruption that may or may not be recoverable (I think I'm remembering that right, as that was something I read up on ~2 years ago when I first built my server, but someone with more experience than I will need to verify if I have that right). See this post by @Stux

The one thing I would recommend is ensuring the eSATA cable(s) you use are 39" or less. While the interface does allow for up to a 6' cable, you'll lower the chance of cable failure with one no longer than 1m[eter].

 

[danb35]

The talk about the crappiness of eSATA cables misses the other major issue with the enclosures you mention, and that's the SATA port multipliers. Those are pretty much universally garbage, as are most add-on SATA cards.

 

[zoomzoom]

@danb35 Are there certain things one should look for, or things to avoid, if having to buy an eSATA PM card? What would be the preferred method if needing to expand to more bays than the main server box has?

 

[danb35]

What would be the preferred method if needing to expand to more bays than the main server box has?

1. Get a bigger box
2. SAS HBA, external SAS cable to a SAS JBOD device.

 

[Stux]

@SwisherSweet Not all. Just be extraordinarily cautious if you need to access anywhere around the eSATA cable(s). Ideally, if you ever need to access the general vicinity of the eSATA cable(s), I would recommend simply exporting the pool, then importing it back in as soon as you've done what you need to do.

IIRC, if a pool is off-lined mid i/o (say due to the eSATA cable), it will cause pool corruption that may or may not be recoverable (I think I'm remembering that right, as that was something I read up on ~2 years ago when I first built my server, but someone with more experience than I will need to verify if I have that right).
.

ZFS deals with this sort of thing. Powering down a pool or part of a pool should not cause corruption.

 

[zoomzoom]

@Stux Does the same apply if the external case is offlined while the pool is still imported and mounted, in the midst of i/o activity?

 

[SwisherSweet]

@Stux Does the same apply if the external case is offlined while the pool is still imported and mounted, in the midst of i/o activity?

I'd like to know the answer to this as well. :)

 

[Robert Trevellyan]

Is RAIDZ1 good enough for a 5-drive 2TB drive enclosure used for backup?

Many people feel it's OK for their backup storage to be less reliable than their main storage. This puzzles me. The one thing I want to know about my backup is that, if my main storage fails, I can rely on the backup. That's why my main storage is on machines with regular SATA disks using regular filesystems, but my backup is on ZFS with redundancy.

 

[danb35]

This puzzles me.

Well, for a problem with your backup to really be a problem, you need to have a near-simultaneous failure in your main storage and in your backup. Even with RAIDZ1, that isn't very likely.

 

[Stux]

@Stux Does the same apply if the external case is offlined while the pool is still imported and mounted, in the midst of i/o activity?

All transactions in ZFS are conducted atomically such that they either compete or don't. There is nothing which can be partial. So as long as the hardware is not lying (like some raid controllers) it should not cause file system corruption. Yes, you might lose the last transaction group etc, but you shouldn't suffer filesystem corruption, which is why there is no fdisk for ZFS.

Of course, there might be bugs :)

 

[Robert Trevellyan]

you need to have a near-simultaneous failure in your main storage and in your backup. Even with RAIDZ1, that isn't very likely.

If you put it like that, even with non-redundant backup disks it isn't very likely (this is a line I use with clients when talking about DAS for onsite backup).

I guess my thinking is based on a scenario where the main storage fails and the most recent test of the backup was a finite time in the past. I want to be confident that the backup is at least no more likely to have failed than the live storage in the meantime.

I get the other point of view, it just doesn't sit well with me.

 

[Stux]

Then it's time to fallback to the offsite backup

 

[Robert Trevellyan]

My offsite backups are (theoretically) more reliable than my onsite backups, which are more reliable than my live storage.