5 ms·

This one counts only if you embrace the cloud :) For me, a RAID-1 does a good job, too.

by giu 17y ago

cynicalkane 17y ago
I'm surprised nobody has said this, but: RAID-1 is not a backup. You're powerless against data damage, and also in trouble if the machine containing the hard drives is damaged.
- giu 17y ago
  It's good that you point it out. Surely it's not a backup, but at least it's a better option than working only with a single harddisk. If you feel comfortable with distributing data in the cloud, cloud storage services like Dropbox are a very good option for backing up everything, as ukmd mentioned it in the comment above.
- Hoff 17y ago
  in trouble if the machine containing the hard drives is damaged Not all RAID-1 has that particular limit. I work with both hardware- and software-based RAID-1 implementations that work just fine across multiple hosts, and that can operate across separations of hundreds of kilometers. And while you're correct about RAID-1 not being a backup; that a volume corruption, errant delete or sufficient degrees of user disgruntlement can still nuke the data. That written, the software RAID-1 solution I use can be used as a component of a backup procedure; you can pull disks out of the RAIDset, clone or archive, and then merge the volumes back into the RAIDset using a delta of the changes. FWIW. edit: added a missing "; that"
  - Periodic 17y ago
    Even when using RAID1 like that for cloning, it's the cloning that is the backup, not the RAID1. You're cloning data that just happens to contain RAID1 configuration data. You could also clone the partition as presented to the OS or the logical files. It's all cloning, just at different levels.
    - Hoff 17y ago
      No. That's not the same. The difference being you can get a consistent copy of the whole disk with a very small window where the applications must be quiesced, where the cloning process you've suggested rolls through the whole volume and (with an active volume) the volume state tends to change as the copy process traverses the volume. As for an alternative and I/O-heavy approach that's possible with the RAID1 implementation, it's also feasible to roll out a member volume and roll in a scratch disk; to replace the volumes using a more traditional scheme. Rolling the member volume back into the RAID1 set after the cloning operation can use the delta of the differences, rather than necessitating a whole-volume copy. Replacing a disk necessitates a whole-disk copy. If you're working with a fairly quiescent disk, then the difference between these two approaches probably isn't significant. If the volumes are busy, then having a complete and consistent copy of the whole volume with a very short window when the applications have to flush and hold can be advantageous.

This one counts only if you embrace the cloud :) For me, a RAID-1 does a good job, too.

by giu 17y ago

This one counts only if you embrace the cloud :) For me, a RAID-1 does a good job, too.

I'm surprised nobody has said this, but: RAID-1 is not a backup. You're powerless against data damage, and also in trouble if the machine containing the hard drives is damaged.

giu 17y ago
It's good that you point it out. Surely it's not a backup, but at least it's a better option than working only with a single harddisk. If you feel comfortable with distributing data in the cloud, cloud storage services like Dropbox are a very good option for backing up everything, as ukmd mentioned it in the comment above.
Hoff 17y ago
in trouble if the machine containing the hard drives is damaged Not all RAID-1 has that particular limit. I work with both hardware- and software-based RAID-1 implementations that work just fine across multiple hosts, and that can operate across separations of hundreds of kilometers. And while you're correct about RAID-1 not being a backup; that a volume corruption, errant delete or sufficient degrees of user disgruntlement can still nuke the data. That written, the software RAID-1 solution I use can be used as a component of a backup procedure; you can pull disks out of the RAIDset, clone or archive, and then merge the volumes back into the RAIDset using a delta of the changes. FWIW. edit: added a missing "; that"
- Periodic 17y ago
  Even when using RAID1 like that for cloning, it's the cloning that is the backup, not the RAID1. You're cloning data that just happens to contain RAID1 configuration data. You could also clone the partition as presented to the OS or the logical files. It's all cloning, just at different levels.
  - Hoff 17y ago
    No. That's not the same. The difference being you can get a consistent copy of the whole disk with a very small window where the applications must be quiesced, where the cloning process you've suggested rolls through the whole volume and (with an active volume) the volume state tends to change as the copy process traverses the volume. As for an alternative and I/O-heavy approach that's possible with the RAID1 implementation, it's also feasible to roll out a member volume and roll in a scratch disk; to replace the volumes using a more traditional scheme. Rolling the member volume back into the RAID1 set after the cloning operation can use the delta of the differences, rather than necessitating a whole-volume copy. Replacing a disk necessitates a whole-disk copy. If you're working with a fairly quiescent disk, then the difference between these two approaches probably isn't significant. If the volumes are busy, then having a complete and consistent copy of the whole volume with a very short window when the applications have to flush and hold can be advantageous.