Whichever backup solution you go with, realize that backups are worthless if you don't test them. This means, having a restore strategy, and actually simulating a complete recovery. You don't have to kill your production data to do this, but you need to make 100% sure that you can actually recover what you need to using your backups. Also version control is not a form of backups, you had best hope that you have a backup of your repository and that you test that you can restore the repository from that backup in case of catastrophic failure. With that said, Amanda is a very powerful tool, if that is what you are looking for. Otherwise, tar, dump, restore, and mysqldump are your friends.
You should take a look at Amanda backups. You can do everything in your list except for the FTP part but you shouldn't have to worry about that since it comes with its own way of shipping the backups around. One of the best things about it is that it stores all the backups in a standard way and they can be extracted without Amanda if you would ever need to do that. There is also a commercial version that has even more features like backing up to Amazon S3.
I've used a thing called rsnapshot, which is a wrapper around rsync. So far have only used it on LAN but am about to try over the internet. Mainly linux support, but you may be able to do Windows with an rsyncd port.
Unless you are storing data in files, I would use version control to keep track of different revisions of the websites code. You could use subversion, but imo git is better.
However, it does make sense to maintain backups to the database. The best thing to do would be to run a sort of cron job which uses MySQL's features to make a backup. These backups can then be archived and compressed. On GNU/Linux the command is mysqldump, but I don't know about windows.