Are you guaranteeing that those files are in a good state when you ship them off? (i.e., flushed and synced to disk)
How about the DBs? Are you backing up the *SQL data files directly (and if so, are you guaranteeing that _those_ are in a good state?), or doing an SQL or other export?
Exactly which files do you need to backup -- user generated content, system configuration, logs, spool files? Do those files give you enough information to rebuild your machine(s) from bare metal? Or have you have documented your setup procedures?
Where are you storing these backups? And how many copies of them, and on what frequency, should you be keeping?
Are you testing your backups? Are you testing your recovery procedures? If not, how do you _know_ they're all working?
---
Sorry for the question dump, but there is a fair bit more to even basic backups than just syncing your filesystem to S3 / tarsnap / The Cloud TM every day.
Simple database backup would be to replicate to a slave (just addressing mysql here for a simple case). Stop replication, backup, restart replication. Easy as that. More complicated scenarios need more complicated setups but hey, we're not talking about saving the last 0.0000001 seconds of data here, this is about losing all your data, from day 1.
Obviously I cannot comment on the specific backup needs for these guys since I don't know their app. However, I can still ensure that an app that is running on a shared hosting environment (meaning - it's not that complex..) has a reasonably good (24 hour snapshot ?) backup potential within a few minutes.
I think it'd have been a decent compromise if they even had a backup from yesterday with a few minutes/hours of effort upfront.
Not saying here that a sysadmin role isn't justified, just that there are a few steps you can follow so that while you don't have a sysadmin, nothing gruesome happens to you.
All of that to say; I agree with what you're saying. I just wonder how to get the message across that maybe both roles aren't the same...
