Do I need to backup my database tables?
You go me there, I can only give you hints though.
In the mid nineties I held a seminar at Park Terrace Hotel in Glasgow. There I introduced the IT community to my phrase: Real men don't take backup.
If the database is static, like I have a table with more than 35000 records of cities and their longitude/latitude, I would certainly prefer to have a copy of the table(s) on at least one other geographical location.
If the database is dynamic, but existing content doesn't change, then it makes sense to save a copy with regular intervals.
If the database is dynamic and existing content is changing, then a copy as such might not make any sense. The table(s) would most likely be out of alignment with the real world and therefore rendered unusable after a short period of time.
If the data are extremely mission critical, then the applications using the database should perform concurrent operations on at least two other hosts at two completely different geographical locations. Parallel database system at the same host is not the solution today, although it might have been so some years ago.
There are several ways of backing up tables in databases. I will limit myself to describe two in this context.
1) Server side automated backups. These are backups that take place in-house and are stored on other disk units. They normally take place once a week here at carl-fh.net. These backups have only been needed once in the last seven years I have been running these services.
2) Client side manual or scheduled backups. These backups are initiated by the administrator of the web site using the database. The client would normally use MySQLadmin, //your.site/msa/, to perform a manual backup. For scheduled backups, you would need to place an SQL script on your web site and use crontab to run the script.
Happy computing
Carl Friis-Hansen