Yes. You should adopt a backup policy that assumes we are storing crates of sweaty dynamite on top of the servers that hold your important data. (Even though we aren't.)
For site content, we use 3-way mirroring to protect live data, we take backups twice per day, and we maintain offsite encrypted backups at an undisclosed location. For member MySQL processes, we have less flexibility but we still take full backups of each process, refreshed daily.
In the event of a serious catastrophe, the most harmful consequence would probably be the loss of everything since the most recent backup, which averages 6 hours for sites and 12 hours for MySQL processes.
That should not trick you into thinking you do not need to make your own backups early and often. If we actually had to restore backups from scratch, the amount of data involved is very large and it would take a really long time, during which you might want a copy of your data.
For sites, tools like rsync, Unison, or version control tools like git can be very helpful in backing up (and controlling the deployment of) site content. MySQL backups are also strongly recommended, especially before undertaking major changes to your MySQL data.
Make your own backups, please!
If for some reason you haven't made or can't use your own backups, we may be able to help. But as much as we love to save the day, there are no guarantees and it stinks when we have to tell someone that we can't help them get their hard work back.