Reply to post: Re: the potential that engineers at the cloud end are also working on data recovery

Microsoft reveals train of mistakes that killed Azure in the South Central US 'incident'

Ken Moorhouse Silver badge

Re: the potential that engineers at the cloud end are also working on data recovery

I had this problem with one of my customers once, and therefore speak with first-hand experience.

Their Netware server hardware died. Having replaced it I then rebuilt the data from a remote backup that I was carryng out nightly on their behalf (Remote as in remote to their location). High priority documents and databases were targeted first, followed by the thousands of images they had built up over the years.

The remote backup was restoring files at the speed expected of an ADSL link. Being jpg images file compression is of no benefit and can make transmission time longer.

Halfway through this procedure I was finding anomalies in what was being restored. Turns out that one of the people who was responsible for some groups of images, frustrated by the delay, had found a local backup of images and had copied those back onto the server. This process was competing against the Remote restore causing mayhem with "file in use" and version problems. With this intervention the whole restore took a lot longer and with many doubts as to whether everything was up to date or not.

This was a problem with someone in the same location as me, in spite of my communicating my methods of restoring data to all staff. Imagine a similar situation where you have no control over the remote end.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon