Support

Highly unlikely doesn't mean impossible. It all depends on PHP's max_execution_time, the file size and the transfer rate between your host and S3. I will quote the manual:

Before you begin, you should know the limitations. Amazon S3 does not allow appending to files, so the archive has to be transferred in a single step. PHP has a time limit restriction we can't overlook. The time required to upload a file to Amazon S3 equals the size of the file divided by the available bandwidth. We want to time to upload a file to be less than PHP's time limit restriction so as to avoid timing out. Since the available bandwidth is finite and constant, the only thing we can reduce in order to avoid timeouts is the file size. To this end, you have to produce split archives, by setting the part size for archive splitting in ZIP's or JPA's engine configuration pane. The suggested values are between 10Mb and 20Mb. Most servers have a bandwidth cap of 20Mbits, which equals to roughly 2Mb/sec (1 byte is 8 bits, plus there's some traffic overhead, lost packets, etc). With a time limit of 10 seconds, we can upload at most 2 Mb/sec * 10 sec = 20Mb without timing out. If you get timeouts during post-processing lower the part size.

If your host's max_execution_time is high enough and the transfer rate is also high enough what you dis is not unlikely at all. Moreover, if you are launching a backup using the native CRON script (backup.php) there is no time limit! The PHP CLI binary sets max_execution_time to 0, which really means infinite. I use the same trick on this site. I have a backup profile with 20Mb part size for the manually triggered backup jobs and an identical profile with the part size set to 0 for the CRON-scheduled backups. The latter transfers an archive file faring at some hundreds of megabytes without as much as a hiccup.

If at first glance it looks too good to be true, check your definition of reality ;)