You'll have to forgive my examples, I'm a Windows sysadmin, but the same tools exist on Unix, I'm sure of it.
How to keep the live server in sync
with staging server?
For HTML and peripheral files, this is simple. Just run a sync at a scheduled time each day. I use
robocopy, but I believe
rysnc will do the same job on *nix.
Goal is to run
the sync everyday but I cant afford
any downtime, so can staging mirror
production yet production be usable by
users during the sync process?
Not usually. If you need to do this, then what you actually need are TWO staging systems. One of them is live, and one of them is idle. You always sync to the idle one, and then switch the staging system over to the idle one once the sync is complete, so the idle one becomes live, and the old live one receives the next update.
Of course, this means that all users will be kicked off the system when the servers switch roles. You say they both have to be up 100% of the time, but really, can you afford 1 minute a day to do this? If you do it at say 3am (or another quiet time of the day) then the impact should be minimal.
And how to automate this process like a cron
There's no simple answer to this. What we do with Windows and MSSQL is to do a
robocopy from the live to the staging to update all the static files, and then do an MSSQL backup/restore over the staging database. This is all scripted and runs once a week, Sunday morning at 1am.
I need to push files from staging to
production, I assume this is done via
FTP or how to automate this also from
There are lots and lots of ways of doing this. Have a look around on this site, it's been asked before.
rsync would probably be the best way of doign this.
For my staging server, how to secure
it internally?... I
cannot use a subdirctory because I
have lots of sub-domains/sub
directories already as part of the
site and I want to preserve the
accurate URL structure for proper QA.
You need a split DNS. The DNS servers that your QA users are on needs to return a different A record than your public users. There's no easy way of doing this. Personally, what we do is we just use a different hostname, so instead of
www.example.com the internal DNS has an extra A record for
staging.example.com. That A record is not exposed to the internet, so only people inside the office or the VPN can access it.
I need to use version control for
code, so i assume SVN is to be
installed on both servers and they can
be in sync although I am not sure how
to seperate them between environments
SVN is a great way of doing this. When we need to deploy to staging ONLY, and not live, we fork the code and then do a checkout on the staging server. That way critical updates can still be deployed to the live system when ready, but the staging system is testing a not-production-ready codebase. Then, when we're done, we merge back into the main trunk and re-check-out the staging server so that they're all back on the same system.