4 ms·
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 configu
by 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 agoNo. 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.