What is your general strategy to backup S3 buckets?
Depending on what data you are storing you may not be interested in backing up data from S3. For instance if you have general website assets that you already have a copy of in a repository elsewhere you probably don't need to backup the assets that live in S3.
Sometimes you may use S3 to store user uploads. These might have originated from an EC2 or they may have gone straight to S3. It makes sense to use Object Versioning to be able to recover from script errors or users deleting files but changing their mind. http://docs.aws.amazon.com/AmazonS3/latest/dev/ObjectVersioning.html
As far as I understand versioning is done on the object level, so if you wanted to "revert to how your bucket looked 3 days ago" you would need to build a script that could check all the versions and dates, and request the right version for each object. This would be possible to do, it just requires a little bit of effort at the application level first.
You could look at other methods, such as syncing all the S3 bucket objects to another service (a third party server, or an EBS backed EC2). This could be your daily or weekly snapshot. This method adds extra costs, maintenance and effort so might not be the best solution, particularly for 5TB of data.
"How do you backup your entire cloud infrastructure? What is your disaster recovery plan?" How to backup Route53? CloudFront settings?
Depending on how far you want to go, all this sort of information should be scripted and in configuration files. Those configuration files should be backed up. This touches on DEVOPS and the concept of infrastructure as code.
How much time will it take to recover from script error or losing access to root console?
This is question sounds difficult to answer. What sort of script error? The first question touches on one example (a script deleting a file that lives on S3) however there are plenty more.
You can look into SimianArmy https://github.com/Netflix/SimianArmy
The Simian Army is a suite of tools for keeping your cloud operating
in top form. Chaos Monkey, the first member, is a resiliency tool that
helps ensure that your applications can tolerate random instance
As for access to "root console" if you're talking about access to your OS, or your EC2s...all that should be scripted via Puppet/Chef or similar and therefore your machines are "throwaway". There is nothing special about them, they contain no individual user data and you can bring one up or down without affecting your system.
If your talking about access to the AWS console, you would need to do things like email or call to gain access, or there may be outages that you need to account for.