At Praxium Labs — Nepal's AI and automation consultancy — we see this pattern across most Nepali engagements. Backups you have never restored are not backups — they are hope. The single most important disaster-recovery practice for any Nepali SME is to periodically prove the backups work.
What "disaster" means for Nepali SMEs
- VPS host failure — provider has a hardware incident or accidentally deletes your account
- Application bug that corrupts data (worse than provider failure — the bad data may be in your backups already)
- Compromised credentials — attacker logs in and deletes data ransomware-style
- Lost employee laptop with the only copy of an important spreadsheet or document
- Internet / power outage at office blocking access for hours-to-days
- Physical office damage (earthquake, fire) — affects on-prem infrastructure
The 3-2-1 backup rule
- 3 copies of your data
- 2 different media (different storage types or providers)
- 1 off-site (geographically separated from primary)
For a Nepali SME: production data on Hetzner VPS (copy 1), nightly backup to Backblaze B2 (copy 2, different provider), monthly archive to AWS Glacier or local NAS (copy 3, different again). Cost: under NPR 3,000/month for typical SME data volumes.
The components
- Database backup: nightly pg_dump (or managed-service snapshot), gzipped, pushed to off-site object storage. Retention: 30 days daily + 12 months monthly
- File / object storage backup: media files mirrored to a second provider or region
- Configuration backup: infrastructure-as-code in a git repository, off-site (GitHub / GitLab)
- Code backup: two git remotes (GitHub primary, GitLab mirror) — sounds excessive, has saved several teams
- Secrets backup: encrypted password-manager export, stored separately
The recovery test
Every quarter, a designated engineer spends 2-4 hours doing this:
- Provision a new VPS from scratch
- Restore the latest backup
- Verify the application starts and a sample of recent data is intact
- Document the recovery time observed
- Update the runbook with anything that surprised you
The first test always uncovers issues — missing schema migration steps, forgotten secrets, an undocumented manual step. Better to find these in a planned test than in an emergency.
The one-page runbook
A simple Google Doc / Notion page lists:
- Where backups live (provider, bucket, retention)
- Step-by-step restore commands (copy-paste-ready)
- Required environment variables and where to obtain them
- Contact details for the VPS provider, payment gateways, key vendors
- Internal: who to call (CTO, on-call engineer, business lead)
- Estimated recovery time (RTO) and acceptable data loss (RPO)
Communications during an incident
Customers tolerate outages they are kept informed about. Operate a status page (Statuspage, Cachet, or just a hosted Notion page) and a WhatsApp Broadcast / email list of customer leads. Within 15 minutes of confirmed incident: acknowledge publicly. Hourly updates. Post-mortem within 48 hours. Communication discipline matters more than zero-defect uptime for SME trust.
The minimum viable DR plan
For a Nepali SME: define your acceptable downtime (RTO) and acceptable data-loss window (RPO). For most: RTO 4-24 hours, RPO 1-24 hours is realistic. Build the cheapest DR that meets those: automated nightly backups to a separate region, monthly recovery test, runbook stored both in cloud and printed. Cost: NPR 5-30k/month. The painful gap: many Nepali businesses have backups but have never restored from them — when disaster strikes, they discover the backup was corrupted or incomplete. Practice the restore. For broader hosting cost context, see our TCO comparison.
Specific Nepal-context risks
- Earthquake — major risk for Kathmandu-based DCs; off-site backups mandatory
- Internet ISP outages — multiple times per year; multi-WAN at office level helps
- Power outages — far less common since 2020 grid improvements but still occur; UPS / inverter at office
- Targeted attacks — ransomware increasingly hits Nepali SMEs; immutable / offline backups are the only reliable defence
- Vendor / staff incidents — key staff leaving without documentation; treat documentation as part of DR
Frequently asked questions
How often should backups happen?
Database: at least nightly; for high-transaction systems, hourly. Files: daily. Config: on every change (git push). Quarterly full-system snapshots. Match frequency to how much data you can afford to lose (RPO).
What's a realistic RTO for a Nepali SME?
For most: under 4 hours from declared incident to operational system. The bottlenecks are usually DNS propagation (~1 hour) and re-applying environment configuration. Below 4 hours requires more pre-staged infrastructure.
Does my managed-service backup count as a real backup?
Not entirely — if the provider deletes your account or has a security incident, you lose backups too. Always have an export to a separate provider in addition to vendor-managed backups.
How do I back up file storage at scale?
rclone is the swiss-army-knife — copies between S3 / B2 / GCS / DO Spaces with bandwidth limiting and incremental sync. Schedule via cron; alert on failure.
What about ransomware?
Critical defence: backups must be immutable (write-once) or in a separate account the production team cannot delete. Backblaze B2 has Object Lock for this. Without immutability, an attacker with broad credentials can delete backups before encrypting production.
Should I back up to a foreign cloud or domestic?
Foreign cloud (AWS Mumbai / Cloudflare R2 / Backblaze) for the geographic separation. Domestic for data-residency-sensitive content (banking, healthcare). Many businesses use both: primary backup foreign, secondary domestic.
How often should I test recovery?
Quarterly minimum for production data; monthly for critical services. Without testing, you do not have backups — you have hope.
Who can build this in Nepal?
Praxium Labs — Nepal's AI and automation consultancy, based in Lalitpur — designs and builds the systems described in this guide for Nepali businesses and for international teams hiring from Nepal. Start a project or see all services.