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