Turn a hosting quote into a clear agreement about capacity, responsibilities, backup scope and recovery, with a practical restore exercise.
Choose hosting around what your website must keep doing. A brochure site updated monthly has different needs from a shop receiving orders every hour. Before comparing storage and price, list essential functions, changing data and the person responsible for each. Bring that list to the hosting options so competing quotes cover the same work.
Turn business needs into answerable questions
Imagine a fictional property office adding photographs daily and collecting enquiries. Its homepage might remain visible while the contact form stops working. Define which journeys must be checked, who receives an alert and what demonstrates recovery. Keep an inventory small enough to update whenever a new service is introduced.
- Does the package cover application files, the database, uploaded images and email, or only some of these?
- What storage and traffic limits apply, and what happens when they are exceeded?
- Who updates the application and server, and who watches certificate and domain expiry?
- Is a separate test environment available, and is its cost included?
- How can files and data be exported when moving to another provider?
To plan the domain account, renewal date and connection permissions alongside hosting, use the domain name selection guide in your handover notes.
Agree how much data and downtime the business can tolerate
Ask two practical questions: how much work could we re-enter, and how long could we wait for service to return? For example, accepting two hours of lost enquiries and aiming for recovery within four hours are planning targets. They require design and testing, may affect cost and do not become guarantees merely because they appear in a proposal.
A daily backup may suit infrequently changed content, but cannot by itself meet a two hour data loss target for enquiries arriving throughout the day. For each data type, record how often it changes, how it is copied and how long previous versions remain available. A source code copy does not include database records or files uploaded later.
Ask what the backup actually contains
OWASP's database security guidance recommends regular backups with protected access and, ideally, encryption. Request a written scope, storage location and list of people permitted to delete copies. Consider how recovery would work if the main hosting account became inaccessible.
| Item | Answer to obtain |
|---|---|
| Scope | Included and excluded databases and files |
| Schedule | Frequency, retention period and failure alerts |
| Access | Who can read, restore and delete copies |
| Cost | Storage, download and assisted recovery charges |
Run a limited restoration exercise
- Choose a copy with a known date and an authorized person to perform the exercise.
- Restore it into an isolated environment with customer messages, payments and external jobs disabled.
- Compare sample pages, images and records against the expected backup date.
- Test essential functions using test data; record elapsed time, missing files and problems.
- Resolve gaps and schedule the next exercise without overwriting the working website.
A successful backup job does not prove a successful restoration. Keep the exercise record and responsible names in your website maintenance plan. Also distinguish communication from storage: Cloudflare explains that TLS protects connections. HTTPS alone does not establish that stored databases or backup files are encrypted.
Barmijly currently provisions hosting manually, with coordination and activation confirmation required. Use contact to confirm the package, responsibilities and actual backup arrangements before relying on them. Add restoration evidence to your launch checklist, including what was tested and what remains outside the agreed scope.