Mixing parity levels in the same pool (the non crazy way)? Plus, saving backup server electricity.

[CompuGlobalHyperMegaNet]

I'm creating a pool using older disks, for use as a backup pool for my primary server. I have 4x relativly new and lightly used 8TB Ironwolfs, a futher 2x brand new 8TB Ironwolfs, and 8x old, used for years, 3TB WD Reds.

I'm thinking about creating the backup pool using two vdevs.... 6x 8TBs in RAIDz2 and the 8x 3TB WD Reds in RAIDz3. I understand why mixing parity levels in pools can my dumb... namely that your RAIDzX vdev counts for squat if you add a stripe. But in my scenario, does mixing RAIDz2 and RAIDz3 in the same pool make sense given the age / state of the disks?

The other question I wanted to put out there is in regards to saving electricty. Again, I know the arguements for keeping servers running 24/7, especially if they leverage ZFS... which is why my primary server is always on, keeping the disk thermally stable, running SMART tests, and scrubbing data. But given that the data on my server is either largely static, easily replaced, or I have a copy elsewhere by the very nature of the data (i.e. Syncthing)... Is there any reason why I should keep the backup server on 24/7?

I was thinking about something like a one week on, three weeks off schedule for my backup server. As a week should be enough time to replicate and scrub the backed up data, and in the three weeks the backup server would be off, it'd be extremely unlikely that my new server would have any new data that I wouldn't have other copies of (be it on camera / phone memory cards, or external disks) or that couldn't easily be reacquired.

 

[webdawg]

I do live replication of data across fiber. It sucks to keep track of some times. I have a ton of different data sets, and 4x devices at one site, and it can be a mess.

I know nothing about mixing parity. It seems like you have the right raid levels for drive size. It all depends how much data, and how much you want to backup. You want to get alerts when stuff goes bad. Non running computer equipment, just seems to fail. I had 5x drives sitting around for something like 5 years, nothing wrong with them, turned them on and each had an issue. OLD WD Greens.

You are right to exercise the equipment, it will need it. Remember, you want automation. Automation, Automation, Automation. If I wanted to do something like this, I would be waking the equipment with wake on lan or something, and shutting it down.

Make sure all the systems sync via NTP to a router or something.

No one remembers anything, and everyone is always busy.

 

[sretalla]

does mixing RAIDz2 and RAIDz3 in the same pool make sense given the age / state of the disks?

I can see where you're coming from here and maybe there's some merit to it.

Remember that any VDEV failure means pool loss, so if you're introducing more risk in one VDEV, I can see why a higer level of risk mitigation would make sense for it.

You shouldn't expect peak performance from that pool and inconsistent read/write performance will certainly be a part of it as data is placed on VDEVs in different proportions.

Is there any reason why I should keep the backup server on 24/7?

It would be important to ensure you get plenty of warning on your more risky disks, so ensuring your server is on to run the SMART short and long tests would be a good idea. Scrubs also sensible. Other than that, it's your call.

 

[Etorix]

What makes sense now to mitigate the higher risk of failure from the old 3 TB drives will no longer make sense when the drives do fail and get replaced by new, larger, drives. Then you'll end up with a raidz2 vdev of middle-aged 6 TB and a raidz3 vdev of shiny new disks: The higher risk of failure will now be on the vdev with the lesser redundancy, the pool will still be imbalanced, there will be no way to remove either vdev and it is uncertain whether there will be a way to upgrade the raidz2 into a raidz3 or downgrade the raidz3 into a raidz2.
This will not age well.

To save electricity, I'd rather try to have less drives—so, get rid of the old 3 TB.