Jump to content

Our Posts


Chuck50
This topic is 7312 days old and is no longer open for new replies.  Replies are automatically disabled after two years of inactivity.  Please create a new topic instead of posting here.  

Recommended Posts

Daddy many are wondering about there posts and numners. Wanting to know if they will catch up after the crash and back up installed? I went over a 1000 again for the second time and loved it. But seriously will they be regained. HUGS chuck

Link to comment
Share on other sites

>Daddy many are wondering about there posts and numners.

>Wanting to know if they will catch up after the crash and back

>up installed? I went over a 1000 again for the second time and

>loved it. But seriously will they be regained. HUGS chuck

 

I'll try. But it doesn't look very good. When the hard drive died it did so in a very violent way and took out two different motherboards.

 

It is possible that I have more recent backups on the 2nd hard drive but have to treat it as suspect. It was hooked up to the 2nd motherboard when it died.

 

Right now, my priority is to make sure that we're stable. Once that's proven (in about a week), I'll start putting the new spare system together so that we're redundant over the two new boxes.

 

Then I'll start a postmortem on the 2nd drive. It'll be slow work, and I'm heavily booked with several short term contracts.

Link to comment
Share on other sites

I'd recommend against trying to restore from an old (but newer) backup, if for no other reason than using an old backup would probably necessitate losing this new set of recent posts. Threads that existed before have now been updated again with new histories and it would seem on the surface to be very difficult to merge a newer backup with this copy, which contains both older threads and a brand-new history as of a couple of days ago.

 

The world will keep turning if those messages are lost. However, there's an old saying in the computer business that the world is made up of two groups: those that have lost data and those that are about to. It's never fun to lose data, especially when it involves replacing hardware, rebuilding machines, etc.

 

Having a reduntant machine is a good idea. But I'd also recommend having a periodic backup -- probably a weekly backup -- copied to a different medium and stored someplace else, preferably offsite. That way, no matter what happens to the hardware, you're never more than a week behind in terms of being able to rebuild a complete system.

 

Congratulations on getting the new hardware in and running. The difference in speed is easily noticeable and the system does seem to be running well.

 

Regards,

BG

Link to comment
Share on other sites

Guest Tampa Yankee

>Having a reduntant machine is a good idea. But I'd also

>recommend having a periodic backup -- probably a weekly backup

>-- copied to a different medium and stored someplace else,

>preferably offsite. That way, no matter what happens to the

>hardware, you're never more than a week behind in terms of

>being able to rebuild a complete system.

>

 

BG,

 

I find myself in general agreement again and join you in congratulating daddy on the recovery.

 

In the software development world daily backups are mandatory because of cost of doing business all over again. And indivdual developers do several backups a day after their first few experiences of pain do to local power interrupts. :( I mention this only because any back system should be automated and if so then doing daily backups is no more difficult than doing weekly backups. I just requires changing a parameter in the bac-up software and monitoring the back-up medium a little more closely -- daily rather than weekly.

Link to comment
Share on other sites

>I'd recommend against trying to restore from an old (but

>newer) backup, if for no other reason than using an old backup

>would probably necessitate losing this new set of recent

>posts. Threads that existed before have now been updated

>again with new histories and it would seem on the surface to

>be very difficult to merge a newer backup with this copy,

>which contains both older threads and a brand-new history as

>of a couple of days ago.

 

I agree, If I can recover more information....I would not restore that backup. I'd isolate the threads that I can, and introduce them into the current database as new threads. That's why I've stressed that it will take time, if it's possible.

 

>The world will keep turning if those messages are lost.

>However, there's an old saying in the computer business that

>the world is made up of two groups: those that have lost data

>and those that are about to. It's never fun to lose data,

>especially when it involves replacing hardware, rebuilding

>machines, etc.

 

and loss of sleep :)

 

>Having a reduntant machine is a good idea. But I'd also

>recommend having a periodic backup -- probably a weekly backup

>-- copied to a different medium and stored someplace else,

>preferably offsite. That way, no matter what happens to the

>hardware, you're never more than a week behind in terms of

>being able to rebuild a complete system.

 

We do periodic backups. We were slowly but surely recovering back from a degraded condition. The general strategy is the older the backup, the father from the primary machine. The latest backups are on the primary machine (usually this weeks and last weeks), the older ones were on the spare machine (the last several weeks), a backup server stores monthly snapshots, and eventually end up on CD and/or DVD.

 

The backups are hampered by two factors. First the Message Center is database driven, and 2nd we're to the point where the MC is busy 24 x 7.

 

When the 2nd machine is in place, I'll be able to use a different strategy that has proven effective with another high volume customer. MySQL can be set up to automatically replicate the database to a 2nd machine.

 

In actual practise the 2nd machine tends to be synced up to within a few seconds of the 1st machine. I can take the 2nd machine down at any time, and it'll automatically synch to the primary when it comes back up. What that allows me to do is take the 2nd database down once a day (or more), Export the database tables, and restart the database without effecting the users. Once the export is done, the file(s) flow automatically to the backup server just like normal backups do.

 

>Congratulations on getting the new hardware in and running.

>The difference in speed is easily noticeable and the system

>does seem to be running well.

 

The old hardware was about four years old (as near as I can tell) and was starting to show its age. Over that time the user load

has increased from 6-12 people on at a time to where we are fairly consistant at about 50-100 people at any given time.

 

We used to have a couple of hours where the system was lightly loaded, and I was able to get the maintaince done at those times. Now days it's 24x7.

 

The new machine is in a word Sweet!. My simple benchmark for speed is memtest and to give you an idea: The standard test on the old box took about 90 minutes...The same test takes about 30 minutes on the AMD64.

 

Now mind you that's with the 32 bit version of SuSE not the 64 bit version. When I have a chance to verify that the 64 bit version is as stable, I expect we'll get another 20% or more improvement. But one step at a time, the secret to really stable systems is small incremental steps.

 

--Daddy

Link to comment
Share on other sites

>

>and loss of sleep :)

 

Yes, that too. I've been there and done that... not fun. :-)

 

<snip>

 

>When the 2nd machine is in place, I'll be able to use a

>different strategy that has proven effective with another high

>volume customer. MySQL can be set up to automatically

>replicate the database to a 2nd machine.

>

>In actual practise the 2nd machine tends to be synced up to

>within a few seconds of the 1st machine. I can take the 2nd

>machine down at any time, and it'll automatically synch to the

>primary when it comes back up. What that allows me to do is

>take the 2nd database down once a day (or more), Export the

>database tables, and restart the database without effecting

>the users. Once the export is done, the file(s) flow

>automatically to the backup server just like normal backups

>do.

>

 

This is a very sensible approach. I've seen it used elsewhere with database-driven systems with good results.

 

BG

Link to comment
Share on other sites

> MySQL can be set up to automatically

>replicate the database to a 2nd machine.

>

 

 

But is he cute and will he bottom?

 

:7 :7

 

Marc <----- tech moron

 

BTW... even us unsophisticated guys with no tech savvy appreciate all that you do (even if we don't understand it).

Link to comment
Share on other sites

Guest mondo

chuck i look at it this way it is like if u get older and wish u could be younger again, turn back time and that is what happened. so enjoy those years (err posts) again.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...