Forum Moderators: phranque
I am responsible for a site that has had two outages in two months, and it's taking too long to get the site back up when it goes out. I dont have the tech vocabulary to understand the issues. My web team reports it has something to do with IIS, or dbs. I'll be learning what this means, but in the sake of time, can you advise on:
-What makes up a good back plan?
-Is there a service we can move the site to and have it back up quickly?
-Can you point me to a link where I can learn what IIS, or dbs are?
And I appreciate your being kind towards my lack of expertise.
I understand this is a forum for experts,
Thanks.
this forum is for everyone, not just experts.
500 pages is not a huge site.
as mentioned by g1smd it is probably the procedure rather than the size that is causing the delay.
are you using a content management system or is it static pages?
If you are acquainted with process modelling techniques the best thing would be to chart the process and step through it noting time scales to find where the main delay occurs, then see if that can be changed. The process may not be appropriate for the problem, for example at my company the only way we could restore a particular service was to have a full restore of the disc from tape which took about two days. Thirty minutes with the vendor's manual and we had a secondary process that created a local back up of the databases which took the recovery time down to 20 minutes.
Check for resets:
A sysadmin friend of mine managing a website programmed his server to auto reset every day at certain hour. The new sysadmin was having complains about this until he found out about the automated process.
The reset thing might involve any automated rollback causing the server to go offline.
Overload:
Your server might be having problems depending on the content you are serving, the process (consuming cpu load) or many many database queries that should be enhanced.
Check your hard drive. A server I had some websites in had this kind of trouble. The result was constant automated "self recoveries" until the hard disk was diagnosed as... dead.
500 pages is not too much (but it depends on your hardware, on your server capacity. I'm running a virtual server now with 20,000+ pages and the cpu load stays below 3% (cpanel).
tph1834, I'm not a server admin (just a webmaster) why don't you try to turn off some features? try suspending perl, asp parsing per example. Check your stats and system reports to see if something is consuming your cpu load, also try to make some folders private (non public). This might help you to diagnose which part of your pages is causing the problems (if any).
You said:
-What makes up a good back plan?
You could compress your whole sites with ZIP or RAR every night or week (and remember to backup the databases), this makes it easier to deal with. You could also use your server backup tool (like Cpanel) to backup your data on your own server (and then download it) or to backup your files to another webserver via ftp (search for cpanel ftp backup and also for wget function to use with the zip-rar files)
-Is there a service we can move the site to and have it back up quickly?
Also you could look for companies with redundancy or failovers.
-Can you point me to a link where I can learn what IIS, or dbs are?just use search engines, your server also has its own documentation which I suggest you read to find software versions, that should be a starting point.
Can you point me to a link where I can learn what IIS, or dbs are?