Suggestion - time and size limits on backup

[rossmcm]

I have a feature suggestion (yes - another one!).

Could you add two parameters to a backup profile - maximum bytes copied, and maximum time elapsed. These parameters would both default to "unlimited", but if assigned would limit the amount of data that could be transferred in a single run of a backup plan. If the time or bytes copied were exceeded the backup would terminate gracefully, except that any file copy in progress would be abandoned. You could also have an option to determine whether any "backup failed" email was sent when the limit was exceeded.

This request stems from the needs of people who have finite internet bandwidths or monthly quotas - as is the case down here in Middle Earth. It would be useful in two scenarios I can think of:

Scenario 1) You create a plan to backup your crucial stuff to S3, and also have exclusions to make sure you don't needlessly copy stuff that doesn't need it - like EXE's, etc. The plan runs unattended at midnight, and generally takes 15 minutes or so.

The next day, somebody at work has a monster debugging session and creates 10 Gb worth of files named Debug001.txt, Debug002.txt, etc.

That night, the plan starts up and copies those files to S3, taking most of the night to do so, and taking a serious chunk out of your internet allocation.

Nobody notices unless their internet bandwidth is throttled before the end of month is reached. You are also paying for an additional chunk of S3 storage you don't need from then on.

If there was an option to limit the time taken, and the plan had this set to (say) 30 minutes, you would get a warning email the next day and would then know to add Debug*.txt to the exclusions.

Scenario 2) You have 100Gb of files you want to transfer to the web, but you aren't in a hurry to get them up there. You have 50G/month allocation of which you normally use 30Gb. If the daily backup plan had the option to limit the data transferred and you set this to (say) 1Gb, the 100Gb would transfer over the next 3-4 months using the "slack" in your allocation.

Thanks for listening,
Ross