Forum Moderators: phranque

Message Too Old, No Replies

building a back up plan - getting a 2nd opinion

         

tph1834

11:39 pm on Dec 19, 2009 (gmt 0)

10+ Year Member



Hello,
I'm not a webmaster, but have a question for you guys.

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.

g1smd

1:43 am on Dec 20, 2009 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



How long is "too long"? How big is the site?

If it is a matter of hours, then that's probably the time it physically takes to reinstate the backup copy, check it out, and activate it.

If it is several days or more, then you really do need a Plan B.

maximillianos

3:12 am on Dec 20, 2009 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



IIS is Microsoft's Internet Information Server. It is a web server.

DBS is the database. Most likely SQL Server. Another Microsoft product.

tph1834

3:49 am on Dec 20, 2009 (gmt 0)

10+ Year Member



Thanks for the replies.
'Too long' is about a day. Site goes up, then fails again a few hours later.
My site has about 500 pages, (I don't know the data size if thats what you are asking)
I guess we have work to do.
thanks.

phranque

7:02 am on Dec 20, 2009 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



welcome to WebmasterWorld [webmasterworld.com], tph1834!

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?

piatkow

2:48 pm on Dec 20, 2009 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



The nature of the failure and the recovery process used are significant. There are so many possible points of failure. Resolution could require anything from rebooting the server through to having a courier fetch back up tapes from an off site location.

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.

explorador

5:55 pm on Dec 21, 2009 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Welcome tph1834, there are many factors involved. First, previous to suggesting the backup plan I suggest a full diagnostic and review on how your server is set up. I could mention a few things (but as I wrote, there are many factors involved)

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?

Being accessible, fast to recover, keeping it updated and yes, redundancy.

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?

As for "backup" yes, I managed several sites with different panels but its been years since I'm only using Cpanel. It has its own backup tool. Hosting companies "offer" you daily, weekly and monthly backups but this is not always true, trust me.

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.

phranque

8:44 am on Dec 22, 2009 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



Can you point me to a link where I can learn what IIS, or dbs are?

The Official Microsoft IIS Site [iis.net]
[webmasterworld.com...]
[webmasterworld.com...]