KENYA · GUIDE 0593 · EDITION 4.2
Backup configuration service in Kenya: Operations and Quality Checks
Deliver the agreed result consistently
Configure backups for identified business data, agreeing ownership, access, retention choices, off-device copies, monitoring, and the recovery tasks the client actually needs.
The operating sequence for this offer is:
- Define critical data, authorized storage, recovery objectives and retention, then choose a backup approach within the owners security and access requirements.
- Configure protected copies and failure reporting, then restore a representative non-production sample to prove recovery rather than assuming successful copying is sufficient.
- Document restore steps, owner access and monitoring responsibility, record the test result and explain what ongoing checks and storage costs remain.
Put acceptance into the job record
A selected backup restores successfully; merely creating files is not proof of recovery.
Ask the owner to restore selected files into a safe location, checking readable contents and documenting unavailable items rather than accepting backup completion messages alone.
Inspect at the point where a correction is still possible, then again at handover. Record rejected or incomplete output separately from accepted output. A completed task is not automatically an accepted task, and an invoice does not establish that the customer received the right result.
Measure real capacity
Time preparation, the main operation, transport, cleaning, approvals and correction as applicable. The slowest stage determines how much you can promise. Where two orders need the same person, space or equipment at the same time, resolve the conflict before confirming both deadlines. An additional enquiry should not erase a commitment already made.
| Operating checkpoint | Evidence for this business |
|---|---|
| Before starting | Configure backups for identified business data, agreeing ownership, access, retention choices, off-device copies, monitoring, and the recovery tasks the client actually needs. |
| During delivery | Configure protected copies and failure reporting, then restore a representative non-production sample to prove recovery rather than assuming successful copying is sufficient. |
| At acceptance | Ask the owner to restore selected files into a safe location, checking readable contents and documenting unavailable items rather than accepting backup completion messages alone. |
| At the pilot review | Record protected locations, excluded data, backup evidence, access ownership, restore results, failures, and the person responsible for checking future backup health after handover. |
Keep a correction and escalation rule
When inputs, access, specifications or customer instructions change, pause the affected work and confirm the effect on time and cost. Do not quietly lower the acceptance standard to avoid a delayed delivery. Keep rework caused by your error distinct from a customer-requested change of scope and agree the remedy clearly.
A backup plan fails when copies exist but nobody can access the account or restore the version needed after a real working-file mistake.
Retain the minimum records needed to investigate a complaint without disclosing unrelated personal information. Use measured delivery and actual acceptance as the basis for expanding capacity, rather than the maximum theoretical output of a tool or production line.
Operating control points for this exact offer
| Sequence | Work method | Release checkpoint |
|---|---|---|
| 1 | Ask owner which content, uploads, settings and integrations must survive and acceptable loss/window. | Schedule follows real change frequency, not a universal promise. |
| 2 | Use supported host/plugin methods for database and site files and record matching timestamps. | A media-folder download or content export alone is not a full site backup. |
| 3 | Store in approved restricted destination and document owner-controlled recovery of keys/accounts. | Backup cannot depend solely on the same compromised site login. |
| 4 | Restore to a non-public test environment, blocking outbound email/webhooks/payment side effects. | Check pages, uploads, login and relevant forms without overwriting live site. |
| 5 | Show owner how to confirm job success, inspect failures and request restore. | A green job flag is not proof of recoverability; retain actual restore findings and unresolved gaps. |
Do not substitute a tick for an observation: record the count, measurement, approved sample or evidence reference used at each checkpoint. Mark unresolved work as held and identify who can approve the recheck.
Diagnose a failure before repeating it
| Observed symptom to investigate | Check the cause | Proposed response |
|---|---|---|
| Restore lacks pictures | Check file coverage versus database-only set. | Restore matching uploads/files and revise coverage. |
| Backup inaccessible after site failure | Inspect destination/key ownership. | Establish independent owner recovery before acceptance. |
| Test sends real email | Check outbound integrations. | Stop restore exercise, isolate side effects and retest safely. |
These are diagnostic prompts, not proof of the cause in a real incident. Separate suspect output, record any correction and repeat the relevant acceptance check. Link rejected units, rework time, replacement materials, customer credits and collection delays to the actual job result.