Time Machine works at a file level, with no facility to perform incremental changes within files. As such, your Sparsebundle may be backed up in it's entirety every time it changes in the slightest, depending on how large it is. Of course, you have to wait up to 1 hour (+the time it take to make the backup, depending on how large the queue is and where your file sits in it) to ensure those changes are included in the backup. Also if your Sparsebundle is in use (mounted...) then it may well skip it until the file lock is freed
This is a terrible system, and one that we might not see change until the underlying filesystem is suitable upgraded (or replaced) to include such useful facilities as incremental block level changes rather than simple file level ones, and/or deduplication etc. One early victim of this scenario were users who used the original Filevault system for encrypting their home folders. Time Machine would not backup their home folders until such time as they logged out because the Sparseimage file was constantly locked by the fact the user had it mounted. And even when the user did log out, it would proceed to make a hugely inefficient backup of the whole thing again and again - on the assumption that they simply logged out and didn't just turn off etc... Not very clever. To try to ameliorate this the Sparseimage spec was ammended to allow for Sparsebundles. Instead of a single big file, a sparse bundle is a bundle (directory) containing a number of files called bands, each in the order of 8 MB in size. This means even though to the end user the sparse bundle appears as a single file, it is composed of smaller files. As of Mac OS X 10.8, the bands are 8.4 MB each. When the content of the image changes, one or more band files is changed, created, or deleted. This allows backup software (such as Time Machine) to operate more efficiently, but it's just a bodge to attempt to mimic block level changes in individual files, which is limited to 8Mb "blocks"...
So to answer your questions directly, 1) it handles them properly, where properly means the same as any other file, it's just that your particular use (leaving it open and mounted) may not result in efficient backups that are taken regularly, especially if you rarely unmount the file, and 2) yes, you will need to pull back the whole file to view it's contents. The TM restore interface is also file specific. It may have quick-look plugins to allow you to view simple files inline like JPGs etc, but not for a complex file like a sparsebundle.
On the bright side, you already have a licensed copy of ChronoSync, which is super useful, and I would continue to use this to perform incremental backups of your sparsebundle whilst it is mounted, you can use the same drive as your TM images too.
The answer is yes and the tool I would use for this task is Disk Utility.
You can use the File menu to select New Disk Image from Folder… and choose only the Backups.backupdb folder as the source of the image.
You can start and see how it works, but I wanted to add some commentary as well since you already are seeing difficulties with other utilities explicitly not wanting any part of cloning Time Machine data.
Since this folder contains hard links, if you don't choose a tool that respects hard links, you will end up with individual copies of each file and not the efficient storage that Time Machine uses.
For network use, you might choose a sparse disk image format which will be easier to copy to S3 and not lose the entire file if the transfer aborts in the middle.
If I were you, I'd perhaps pick important backup intervals and only move those to the offsite storage, but networks are fast enough that you could push an entire backup set to the cloud if you didn't mind paying the data transfer costs and waiting for the upload to be written to S3.
Best Answer
Time Machine use an incremental backup approach, where each backup only contains the differences since the previous backup. For a single, changing, file over time, Time Machine keeps state snapshots of the file so you can move backwards in time and see how the file was at previous, different states.
As the disk fills up, Time Machine will purge the oldest snapshots it has. Time Machine will do this opportunistically to ensure that your backup disk always has enough free space to store the next incremental snapshot of your live data it wants to make.
Time Machine doesn't back up everything. It has user-specific exclusion lists as well as a built-in exclusion list. Because of this, the target backup drive doesn't need to be many times bigger than source drive, only a few times bigger than the data set on the source drive that it will be backing up. You can exclude the operating system files for the most part.
For example, on this Mac, you can see that even though there's over 500 GB of storage used on the Main drive, the Time Machine drive isn't 100% full and actuall stores many, many months of incremental backups:
My rule of thumb is you'd like 2x the amount of data you have if you want a long history. But you can get by with 1.5x if all the files on your source drive aren't changing frequently which is true the vast majority of the time.
If you just want to make regular, scheduled, clones of your drive you can use something like Carbon Copy Cloner, which includes a feature for scheduling clones, to take a snapshot of your source drive to a target drive that doesn't contain incremental backups, but is made by taking an incremental update approach. It will only update files on the target if they've changed since the last backup was made and the target drive will only contain the state of your source drive as it was the last time a backup was done.