1) I'm pretty sure there isn't any pre-available automatic way to achieve this. One day AWS Lambda will probably be capable, when it is taught how to receive an event after the RDS backup has occurred.
2) I think you've misunderstood what the RDS backups do. They actually take a snapshot of the RDS instance (i.e. the hidden EC2 instance on which the RDS instance is running). There is no database dump file which you can obtain and store or use outside of AWS. Restoring an RDS instance backup is actually spinning up a temporary new RDS instance from the snapshot, then copying your data round (or pointing apps to the restored instance)
I'd strongly recommend use of a script that uses your DB-specific dump tool (mysqldump, pg_dump, or whatever it is for SQLServer) to dump the production database from the production RDS instance, then import that into a pre-existing staging RDS instance, on whatever schedule you like.
I have had some perspective on this in the last few months & I believe these items to watch will address all the concerns above:
1) The comment from @Ross on the original posting is the key. T2 instances, no matter what scale and no matter whether they are EC2 or RDS, will stop performing when their CPU credits run out as the peak CPU demands continue.
2) The failure mode of a CMS web server we have seen most often is shown exactly by this condition: the CloudWatch graph dives towards zero when the CPU percentage needed by httpd processes exceeds the CPU percentage assigned to that instance type (see doc link below).
3) The quick solution for a T2 instance that has exhausted CPU credits is to shut down, upgrade the instance type, and start up the instance again, which takes about 3-4 minutes. The most vital description of the capacities of different instance types is here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html
4) Any production web server on AWS must have an Elastic IP address assigned in advance for this reason: if not, and the instance is rescaled, the IP address will change, leaving the web server inaccessible far beyond what would otherwise only be 3-4 minutes of downtime.
5) The only way to acquire more CPU credits is to upgrade the machine type. The amount of credits each T2 instance size can hold is described in the doc link above: it is always equal to the CPU work that instance type would do in 24 hours.
6) The machine can be returned to its original scale during a bit of scheduled downtime (again, 3-4 minutes) after peak performance demands die down.
7) I/O activity hasn't caused any performance degradation for our web server in any peak periods so far. The amount of IOPS is determined strictly by EBS volume size. Both the exact meaning of IOPS, and that relationship, are described here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-io-characteristics.html
8) Neither of the Cloud Watch metrics Freeable Memory nor DB Connections were of any use anticipating or correcting performance problems in a web server intensive environment.
Best Answer
It sounds as if you are trying to use a snapshot in a way it isn't intended to be used.
You don't load an RDS snapshot onto an existing system.
You use a snapshot to create a new system whose data is an exact duplicate of the system where the snapshot originated, at the time the snapshot was created.
Rename the staging db you created, calling it something else. Then create a new instance from the snapshot, giving it the original name of the staging db. You should find that the new db instance has the same endpoint hostname that was assigned to your original one, and your staging environment connects to the new machine, though the app server might require a restart or reload to recognize the DNS changes that RDS takes care of in the background. If all goes well, delete the old staging instance.
On the other hand, if you have multiple databases and you only want a subset captured from prod and cloned to stage, you won't use snapshots for this... you'll want to use standard administrative tools for your database family to extract data from prod and load onto stage.