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"
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.