I want a complete backup of my server. It's CentOS 5.
My thoughts: I can literally take every single file on the server and back it up, and I'll have a backup of everything. Server config, my PHP files, MySQL DB, EVERYTHING... is this an accurate assumption?
I was going to backup MySQL additionally, but perhaps that's not necessary since the DB files are included in my Server backups?
Further... I'm trialing RackSpace Server Backup. This basically takes every file on my disk, and backs it up over SSL, and encrypts the data on the backup disk. I can run it every day, and only "updated files" are sent to the backup destination.
Thanks for the help here...
I can't agree with Nils. I admit that I can't speak to MySQL, but I can say from experience that that is not true of Oracle.
Taking a snapshot of the database files on disc is fairly meaningless even if it's instantaneous. The DB contains many transactions, some of which are nearly completely flushed to disc, some of which are partially flushed, and some of which remain almost entirely in RAM. What's on-disc may be recoverable with DB tools, but it's unlikely to be a workable database.
Worse still: for any sizeable database, backups will take some time, and that means disc-only backups are downright useless. Think of it as a very blurry snapshot; you photograph something moving quite fast (your DB) and you hold the shutter open for the time required to take the backup (20 minutes? 2 hours? 28 hours? (for some of my production DBs)). The photograph will be very blurry; you'll catch some tables early, with few transactions committed to disc; others you may catch many hours later, with some hundreds of thousands more transactions on-disc by then. I can't say that your disc backup won't work straight-off; I can't even say that you won't be able to recover from it with DB forensic tools; but I wouldn't trust my job to it.
If your FS supports snapshots, and your DB supports hot-backups (or equivalent), those can work. Hot-backup is an instruction to the database to quiesce the tablespaces; it buffers all pending transactions on some kind of logfile, and applies them en bloc when you take the tablespaces out of hot backup state. This can work while you quiesce the tablespaces and back them up to tape, but it works an absolute treat if you can quiesce the tablespaces, snapshot the underlying filesystem, then release the tablesapces from hot backup and roll the snapshot off to tape.
If you can't manage that - and I often can't - then what I do is tell the backup software to ignore the datafiles entirely, and have MySQL run mysqldumps to online storage first, then roll that off to tape. I've never had a problem recovering from those.
But as I always add in these cases, whatever you do, you should document it well and test it frequently. That last is more vital than any other tip. If you know it works, who cares what you're doing? You can back up using zip to WORM archives written on the wing-cases of cicadas, if it's known to work reliably. But if you aren't testing it, who cares what the talking heads of serverfault say? It's not fit for purpose.
Basically yes - everything is a file. But: the files on disk cntaining the data my be inconsistent due to the fact that some data is still in RAM-cache and has not yet been written to disk.
So I you backup a DB under heavy load just using file-backup you might loose some transactions. The safest way to have a complete backup by file is shut down the DB, sync the disks and then start the backup. Or use DB-means to backup the database contents to disk - these backups will be - more or less - consistent. In mySQL you can choose different backup modes...
EDIT: Try mysql-Administrator (if you have it available). There you can specify backup-jobs via GUI. The result will be a corresponding backup-command as cron-job using your backup-specification.