Entities are expected to be autonomic... They should know how to dump/restore themselves. So entities provide effectors for managing dumps. For example, see the effectors in this Minecraft blueprint: https://github.com/johnmccabe/brooklyn-minecraft
A policy would handle the retention schedule by using those exposed effectors. For example, a policy could use the effectors make/keep daily dumps for a month, then roll to weekly/monthly further back.
Entity storage is effectively volatile... we don't want our dumps stored there. For persistence outside the entity itself, the entity needs to know a non-local location to put/get/list the dumps. So the entity can take a blobstore URL+creds as a config value, and use that as its storage, with curl. (Entities can be composed in other blueprints. So maybe you could wrap an entity around the Minecraft example that provides non-local backups using the local dumps it makes.)
Since the config value is passed in, it can cascade from the top of the blueprint, or Brooklyn itself. So for example, you could configure Brooklyn with a "backup_blobstore", and every entity Brooklyn manages that has a backup policy attached would dump/restore there. You could also specify a different blobstore per blueprint, and potentially for each entity down the hierarchy of that blueprint, which overrides the level above.
Then when you run Brooklyn in Cloud Foundry, you could just supply any blobstore as a config value to Brooklyn itself. And you could enable people brokering services instance via the Cloud Foundry Brooklyn Bridge to supply their own blobstore as a parameter to override that for their particular service instance.