jump to navigation

Uptime June 20th June 20, 2009

Posted by ismywebsite in general.
Tags: , , , , , , , , , , , , , , , ,
3 comments

I’m planning on starting these, just to give a vague idea of which nodes are most reliable at any given time. This should help a lot for those people who need to have their sites online reliably. Nodes are listed in order from most reliable to least reliable.

Node 6 – Nixism
Uptime last 14 days – 100.00%

No current issues.

Node 7 – HighLayer
Uptime last 8 days – 100.00%

No current issues. Not open to new accounts.

Node 2 – Felweb
Uptime last 14 days – 99.84%

No current issues. Not open to new accounts.

Node 1 – SmokyHosts
Uptime last 14 days – 99.53%

In process of storage upgrade.

Node 3 – OSHS
Uptime last 14 days – 98.76%

In process of storage upgrade. Not open to new accounts.

Node 5 – Addora
Uptime last 14 days – 97.79%

No current issues.

Node 4 – GalaxyHosts
Uptime last 14 days – 40.68%

Use of this node and company has been permanently discontinued. Why?

In the future, I will publish trends and changes in the uptime of servers, which should be helpful to gauge where to locate your website. Keep in mind that servers are judged on multiple aspects, including speed, security, and flexibility, and no server will be the best in all areas.

Lots Of Apologies June 18, 2009

Posted by ismywebsite in general.
3 comments

It’s got to come out sooner or later, and of course I could definitely see this coming. At this point, it would appear our data from Node 4 is completely inaccessible. All copies that exist:

1) The account with Galaxy Hosts appears to the best of our knowledge to have disappeared along with all our data, and our friend Patrick hasn’t replied. Either his support system has gliched again, he’s ignoring us entirely, or he’s just not man enough to tell us that the data’s gone.

2) The copy which was rushingly backed up by the one volunteer who I managed to find has been locked away at a location he will not visit for 2 and a half months again.

3) I did a backup of a small percentage of the accounts on my own. These still exist, and have all been restored.

4) The copy you backed up, and keep regularly up-to-date, which you are welcome to restore at any time.

In all honesty, we can blame and point fingers around that table at who’s fault it is. I might as well take all the blame for how this turned out, since that’s usually what ends up happening anyways, but the fact is, I believe there’s only one person who is truly blameless in this whole endeavour, and his name is Kristoffer.

Why is he blameless? Because he actually replied to the blog post and offered his services moving accounts over. He was the only one. Unfortunately, I don’t really know him very well, and I didn’t want someone who I’ve just met yesterday handling your data, as much as I believe in him and the application process I’ve set up.

The other fact I know is that I don’t want this to ever happen again, so I’ve outlined the exact procedure to be followed in the future when we have to deal with this type of thing again:

On Initial Notification
-Blog post about potential transfer
-Inform volunteers

1 Week Prior
-Send out email to all users of node
-Perform a cleanup of server accounts

4 Days Prior
-Send out PM to all users of node
-Divide server accounts between volunteers

2 Days Prior
-Confirmation with all volunteers
-Assign replacements if necessary

1 Day Prior
-DNS update commences
-New cPanel accounts created

Day Of
-All volunteers gather backups
-All primary backups transfer over

Day After
-Any secondary backups will be restored

As a transfer volunteer, you would be expected to always check your email and be able to respond within 48 hours. In the event, you are contacted, you would be given a specific 12 hour timeframe within which to:

  • Gather 50-100 Primary Backups, which are tar.gz files that are stored on your computer. These will be selected for you and presented in a list of links.
  • Restore these 50-100 Primary Backups to the new server by uploading them.
  • Gather 50-100 Secondary Backups, and keep a copy of them on your computer.

Over the next 24 hours, you would then:

  • Restore these 50-100 Secondary Backups by uploading them to the new server, and/or,
  • Delete these 50-100 Secondary Backups as requested.

It’s not a hard job at all. It’s just time-consuming, and we must always have someone available to do it.

To deal with the privacy concerns of such a policy, we will be adding a setting within each user account as to whether you would like this service or not. Any users who uncheck the option will receive no help with transfering over their files.