I don't think it's a ridiculous answer.
The only way to prevent dataloss in the event of a volume corruption/IO stream failure is having a copy of the data in a different location. In other words: a backup.
I'll give a plausible reason for dataloss in this case: Synology DSM uses kernel 2.6.32 and SHR uses MDADM for the RAID volumes which are merged together using LVM on which an EXT4 volume resides. The standard SATA disk that is available today has anywhere between 16 and 64MB of on-disk write cache to enhance performance as well as Native Command Queuing (NCQ). I'll assume on-disk write cache and NCQ have been enabled (Synology default). MDADM has a queue as well that can contain 1024 operations (Synology default for RAID5 sets).
The data for the LVM volume is written to MDADM. LVM in combination with this kernel version and EXT3 or EXT4 is known to screw up some journalling in case of a disk drive failure caused by a lack of barrier
This has been fixed in kernel 2.6.33
Worst case: MDADM RAID5 write hole
In the Worst Case event of a drive failure, the MDADM RAID set fails because the write hole screws up the superblock persistency, taking a significant part of the LVM volume with it, causing the LVM volume to crash and take all your important data with it. Synology support is usually able to restore most of your data but you will encounter downtime. (You can also restore it yourself if you know how to use the command line.)
To eliminate the use of LVM I'd use standard RAID on a Synology device.
In my opinion, getting a Synology DiskStation DS1511+ for redundancy and/or fault tolerance is ridiculous. The only part that's redundant is the RAID set and that redundancy hinges on a software implementation. That being said: contact Synology support. They're committed to the product and can really help you with troubleshooting and maybe a solution. My first step would be to get rid of LVM.