On Thu, 2024-01-18 at 13:09 +0000, Michael Kjörling wrote: > On 18 Jan 2024 13:26 +0100, from r...@h5.or.at (Ralph Aichinger): > > As a home/SOHO user, I'd rather have a working backup every few hours > > or every day than some RAID10 wonder > > Definitely agree that a solid backup regimen (including regular > automated backups; at least one off-site copy _at least_ of critical, > hot data; and planning for the contingency that you need to restore > that backup onto a brand new system without access to anything on your > current system -- think "home burns down at night" or "burglar" > scenario) is the _first_ step, and one that a great deal of people > still fail at. > > RAID is for uptime.
It's also for saving you from the hassle involved with loosing data when a disk fails. > If a week-long outage (to get replacement hardware and restore the > most recent backup) and a day's worth of data loss is largely > inconsequential, as quite frankly it likely is for most home users > save for the cost of replacement hardware, that's a very different > scenario from if that same outage costs $$€€¥¥ and could destroy > your livelihood; and consequently the choices made _should_ likely > be different. That's assuming your time isn't worth anything and ignores whatever the loss of data may cost you. If that isn't relevant to you, you don't backups, either. > _Mirrored backups_ makes very little sense to me. If a storage device > used for storage of backups fails prematurely, just toss it and get a > new one and make a new backup. If the backup software goes haywire and > starts overwriting everything with random garbage, having the garbage > mirrored isn't going to help you. It's much better to have two > independent backup targets and switching between them, and figuring > the switching interval into your RPO. The only time when something > like mirrored backups will help you is when you have only one backup > set, the backup itself works fine, but a backup drive fails, _and_ the > source fails before you've been able to make a new backup. That's a > _very_ narrow scenario and easily solved by having two backup sets. Having multiple generations of backups already increases the needed storage space by a bit more than half. That makes it already arguable if it's better to make (multiple generations of) backups on a single RAID or on N single disks. Any of the disks can fail at any time. If you go with N == 2, a RAID (with multiple generations of backups on it) can be better because when a disk fails, the RAID will very likely survive and the non-RAID may not. So for daily use, I'd ideally make multiple generations on RAID and copy the latest generation to somewhere off-site, using either single disks, or another RAID. Having no hassle and no downtime at the production system and instead having hassle and downtime off-site may be much more desirable than having it the other way round. Trying to make things appear easier by pointing out that failed disks can be replaced is not helpful. Replacing a disk in a RAID isn't any more difficult (and can be much easier) than replacing a disk that isn't in a RAID.
