Are these questions so poor that nobody can answer them? Maybe they've gone to the billing department at Lunarpages by mistake - *those* guys can take a week to answer! 

My site is still in the process of being transferred, so I don't have access to anything yet, but I'm really trying to use my time wisely and learn.... please guys, throw me some info.....50+ views and no reply even to tell me how dumb my questions were? 

Thanks for all that.

1/ Ok...so the backup FTP account - I note that it says on the VPS sales page that it costs $25 setup and $20/10Gb. Is that a monthly cost, or just one off?

2/ Thanks for the info - just to further elaborate, what I'm worried about is whether my site is actually less secure under VPS than it was under Basic Hosting?

Thanks for the information. Forgive me as I continue to ask more questions! 

So, If I have extra space available as backup for FTP, and I have several databases, each consisting a few dozen tables, each database being about 1Gb in size...

Ideally I'd like to keep the backup databases as current as possible to minimise data loss..... Some tables only receive inserts, some tables are updated regularly...... I really don't know what strategies to use? Has anyone got any advice?

EDIT: Would this method of MySQL replication be possible using the FTP backup space? http://www.softwareprojects.com/resources/programming/t-how-to-move-copy-a-live-mysql-database-1257.html

For anyone that is interested, what I have chosen as my 'backup' strategy is to set up replication as per http://www.howtoforge.com/mysql_database_replication by purchasing a second VPS on another physical server to act as a slave.

I have chosen this because I'm not worried about "bad" data coming from my application per se - I can deal with undoing updates to the game database using transaction logs etc if need be, and I test things thoroughly prior to any major implementations. My main concern here is actual backing up - ie safeguarding against a server crash.

I'll get back to you in the next day or two and let you all know how it's going - currently got itchy fingers and tired eyes waiting for the techos to confirm that they are starting to move my site from Basic to VPS 

Well, in theory it should be brilliant. In reality, I strongly advise anyone that wants master/slave replication to leave it alone, unless you know how to do it yourself. 

Lunarpages managed to recover some data that wasn't toooo old for me....but couldn't manage to successfully restore it.
Neither could they manage to restart mysql replication for me, or a few other general server-debugging tasks. Well, maybe they might have been able to do it but after almost a week of continual downtime I was not really wanting to sit around waiting for technical help.

I strongly recommend anyone considering mysql replication to learn how to do this yourself, because if anything goes wrong, you're going to have to fix it without any reliance on tech support.

So..in the past 72 hours (never having logged into a command shell before in my life excepting my Amiga 20 years ago!) I have learned how to:
1/ rsync files from one VPS to another
2/ start and stop mysql & replication
3/ Change a mysql password from a root SSH
4/ obtain status reports on master/slave relationship and use those to debug mysql replication
5/ Manually bring replication back into sync
6/ monitor replication and use mysql command line to manually/randomly query the slave database to verify consistency with the master

I'm pretty impressed with myself. Now, the next step in my learning - shell scripting.

If anyone can help at all, that would be cool, but I'm expecting to probably have to work this out myself.
My database backup policy is this (and I need to write a script to do part 2 via CRON)
1/ Master -> Slave replication (over 2x VPS - insurance against a primary server crash)
2/ Every 12 hours on slave
         a/ Stop mysql
         b/ cycle through all mysql databases (all have directory name xxxx99_databasename)
               i/ myisamchk the tables in this database.
               ii/ if the database has no errors, zip a copy of the raw database directory and send an email to confirm this database backed up
               iii/ if the database has an error, take no action but email to warn of the corruption to slave database
         c/ if there were no errors at all in any databases during step b, then delete the zip files that are older than 24 hours old.

I figure thats a fairly secure policy - it means I have accurate up-to-date data spanning 2 servers, and also 2xhistorical data files which are guaranteed to contain "good" tables....and a ready-warning system whenever database corruption occurs

Anyone able to help me write a script like this? Or give me a pointer on where to start?

Yep - I've written a script that is working fine. I had no knowledge of scripting before but it's come off ok and doing its' thing 

It follows the pseudo code I wrote above...although I omitted the "conditional backup based on mysql check" at a later date, because it seemed that sometimes the slave was shut-down mid transaction and so the mysqlcheck was failing. At least I think that was what caused it! It makes sense I think anyway...I imagine that even when the slave shuts down, mysqld would still have a transaction or two to write, and so the mysqlcheck was spotting them in progress and giving a warning.

If anyone needs a copy of the script I'm happy to share it.