This evening we will be completing the migration to the new server.

Primary DNS has already been moved to the new server.

Tuesday 6:00PM - Website data will be backed up, this will take 3-4hrs.
Tuesday 10:00PM - Website data will be restored to the new server, this will take 2-3hrs.
Wednesday 1:00AM - IIS Metabase will be duplicated to the new server and updated with the new IP addresses, 10-15mins.
Wednesday 1:20AM - DNS will switch to the new zone files with updated IP addresses
Wednesday 1:30AM-2:00AM - Random websites will be tested to see if they function correctly.

The MSSQL Database Migration to the new server has completed.

Total Downtime for MSSQL was 4mins.

If any users have any database issues please contact support.

EMERGENCY MAINTENANCE WINDOW ANNOUNCEMENT

WINDOW: Friday June 22nd 22:00 - 23:59 GMT
ESTIMATED DOWNTIME: 10 MINUTES
NETWORK IMPACT: PARTIAL
DESCRIPTION:

Our provider will be swapping out a switch in lon1 (iP House) which they believe may be the cause of VRRP issues they are currently seeing and replacing it with a new Cisco 2960G series switch. This will mean that all devices are standard.

All customers will lose access to the network for a couple of minutes as this switch is swapped out.

We apologise for the short notice on this maintenance period however we believe it is neccessary to perform this work for the ongoing health of the network

At 18:01 BST our providers VRRP (Virtual Router Redundancy Protocol Setup) once again become unstable. This outage lasted for approx 30mins.

They have, today, collected 6 hours worth of tcpdump data to send to their equipment suppliers to attempt to see why this is happening. We will keep everyone updated through to a resolution.

We apologise for the inconvenience.

We need to reboot Server SGC for windows update to complete its process.

At the same time we will also be renaming the server in preparation for its migration.

This will take approx 5-10mins maximum.

We have scheduled this for 1:30AM this evening.

We have been aware for the past month that AWStats has been running very slow. On investigation we thought it could be something to do with the version of AWStats we were using so this was upgraded from 6.5 to 6.6 last week.

This had little effect on performance. We had a closer look at the data structure the control panel uses to store AWStats data, we discovered they use one folder to store all websites statistical data, the total files in this directory was 68,124. This is a rather large amount of files for one directory and explains the slow AWStats performance and heavy disk i/o activity.

To fix this we have placed each websites stats in a subdirectory of the main data folder, this has made a rather instant improvement to performance. AWStats now loads with very little delay.

Due to this discovery we have asked the control panel company and they have agreed to moving all statistical data to sub directories in the next update due at the end of this month.

The delayed memory upgrade to server Atlantis will take place on Monday 18/06/2007 between 20:30 and 21:30 BST.

There will be a 5-10min outage for any sites hosted on this server.

Also our Primary POP3, SMTP & Webmail will be unavailable. mail will be collected by our secondary mail server during the outage.

If you need to access webmail during this outage please go to http://mail2.gbdns.net and login as normal.

Over the past 2-3 days we have noticed an error appearing from the raid controller on Server SGC.

From further investigation this looks to be either a faulty cable or a failing hard drive.

We will be replacing the SATA cable this evening. This work will be done A.S.A.P due to the possibility of data corruption.

There will be a 10min window where all websites on Server SGC will be unavailable. Mail and websites hosted on Server Atlantis will be unaffected.

If the replacement cable does not solve the problem the hard drive will be disabled and then replaced on Monday evening.

We appologise for the short notice for this maintenance, but we believe a proactive response is required to maintain data integrity.