This is probably due to the way that cloning works; in short the LUN in the snapshot is mounted but is read only, any changed blocks are written to the next available blocks in the volume. However the cloned DB relies on the snapshot that it was created on and that snapshot is locked as long as the clone is in existence, if you were then to backup the cloned DB you'd end up with a long and complicated chain of locked snapshots which would then screw up the retention policies as the snapshots wouldn't be able to be deleted.
The best way to backup a cloned DB would be to manually clone the required LUN or the complete volume using the snapshot created by SMSQL, then split off the cloned LUN/volume so it isn't reliant on the snapshot anymore. Be aware that you'll need to have sufficient free space in the volume or aggregate as the split off LUN or volume become entities in their own right. You could then mount the clone and the DB within it, rerun the SMSQL config wizard so it's aware of the clone DB and it's location, and back it up.
