Service

Rescue & Recovery

Something is down, defaced, or has been quietly wrong since an update three weeks ago. The first job is to stop the bleeding. Establishing how it happened comes second, and it does come.

Request thisPriority response

Engagement
Hourly until stable, then quoted
Response
Same working day where possible
Access needed
Hosting, DNS and repository, or whatever exists
Best for
An emergency, or an inherited mess

Deliverables

What You Actually Receive

Named up front, so there is something to hold the work against when it is finished.

01

Stabilisation

Get the site serving, get the bleeding stopped, get a known-good backup taken before anything else is touched.

02

Establish What Happened

Logs, file timestamps, database state and version history, read carefully enough to say what the entry point was rather than guessing.

03

Clean Recovery

Removal of what was injected, rotation of every credential that could have leaked, and patching of the route in, not just the symptom.

04

Plain Written Account

What happened, when, what was exposed, and what it will take to stop it recurring. Written so you can forward it to a client or an insurer.

In detail

How The Work Runs

The First Few Hours

Nothing is deleted before it is captured. A compromised site is also the only evidence of how the compromise happened, and destroying it to get back online faster means the same route stays open.

The order is fixed:

  1. Capture. A full forensic copy of files and database, before anything is touched. It is the only record of how the compromise happened.
  2. Contain. Take the site off the public internet or put it behind a holding page, rotate the credentials that are obviously exposed.
  3. Restore. Bring back a known-good state, or clean the current one if no good backup exists.
  4. Investigate. Read the copy (logs, file timestamps, database rows, version history) until the entry point is known rather than assumed.
  5. Close. Patch the route in, rotate everything that could have leaked, and write down what happened.

Where that order has to be broken because the business is losing money by the hour, that is a decision you make with the trade-off stated, not one I make quietly.

Getting the site back up without finding the way in means doing this again in a fortnight, with the same people and a worse mood.

Inherited And Abandoned Projects

Not every rescue is an incident. A developer stops answering, an agency folds, or a contractor leaves behind something nobody else can deploy. The work is the same shape: establish what exists, get it into a repository, get it deployable by someone other than its author, and write down how.

Access is often the hard part. These have a habit of being registered to whoever set them up, and recovering ownership is usually the first task and occasionally the longest:

  • Domain registrar and DNS
  • Hosting control panel and SSH or SFTP
  • The repository, if one exists
  • Payment gateway and any subscription billing
  • Email and transactional sending
  • Analytics, tag manager and search console

Bring whatever you have, including partial or uncertain credentials. Knowing which of these you cannot access is itself useful information.

After The Emergency

Once it is stable, you get an honest assessment of what you have: whether it is worth maintaining, worth rebuilding, or worth moving. That assessment does not assume the answer is more work for me.