Cloud backup for Indian businesses: a plan that actually restores

Why backups fail when you need them

Backups fail in predictable ways. They were never taken. They were taken but stored on the same server that failed. They covered files but not the database. Or they existed, but nobody had ever restored one, and the format, password or size turned out to be a problem on the worst possible day.

Every one of these is fixed by a little planning and one test restore.

The 3-2-1 rule, made practical

Keep three copies of anything that matters, on two different kinds of storage, with one copy away from the server. For a website that can be: the live site, a backup kept in your hosting account, and a downloaded copy on your own computer or in object storage. For a cloud server: the server, continuous backup, and periodic exports to object storage.

• 3 copies: live + two backups
• 2 kinds of storage: e.g. hosting account and object storage
• 1 copy off the server: downloaded, or in a different storage service

Backing up a hosting project

On Cloud Ninza, open Backups in the dashboard, choose the project and press Make a backup. The site's files — or the app's code and settings — and every database on the account go into one archive. Download it straight away, keep it in your account (it counts in your storage until you delete it), or both.

Make one before plugin updates, theme changes, new releases, imports and anything you are not sure about. When you change a project's blueprint — for example from WordPress to a Node.js app — the switch screen offers the same choice: keep a backup, download one within 24 hours, or keep nothing.

Backing up a cloud server

Servers need two layers. Continuous backup captures changes as they happen so you can restore to a point in time — the right protection against a bad deploy or a deleted table. Object storage holds periodic exports and database dumps away from the server, priced at ₹750 a month for the first slab and by the gigabyte beyond it.

Database servers deserve their own dumps on a schedule, because a consistent dump restores more reliably than a copy of database files taken while they were being written.

How often should you back up?

Match the schedule to how much work you can afford to lose. A brochure site that changes monthly needs a backup after each change. A shop or booking site that takes orders all day needs frequent database backups — and continuous backup if it runs on a cloud server. Ask: if the server disappeared now, how many hours of orders, bookings or content could we re-enter by hand? That number is your backup interval.

Test a restore — at least once

Pick a quiet day, take your latest backup and restore it somewhere harmless: a staging subdomain, a local machine, or a spare cloud server billed by the hour. Check the home page, sign in to the admin, place a test order. Write down how long it took and anything you had to look up. That note is your recovery plan.

Security of the backups themselves

Backups contain everything an attacker wants — customer data, passwords in configuration files, database dumps. Keep them in private storage, not in your public web folder; we regularly find downloadable .sql and .zip files in web roots when moving sites from other hosts. Delete old backups you no longer need, and protect the accounts that can reach them with two-step verification.

What exactly is in a project backup

A Cloud Ninza project backup is one compressed archive with a short README, a folder of database dumps — every database on the account, each as its own .sql file — and the site itself: the web folder for WordPress and PHP sites, or the app folder and its settings file for Node.js, Python and Java apps. Dependency folders such as node_modules and Python virtual environments are left out, because they are rebuilt from your code and only make the archive larger.

Because the archive is ordinary tar.gz with plain SQL inside, you can open it on any computer and restore it anywhere — another host, a local machine or a new Cloud Ninza account — without special tools.

Retention: how many backups to keep

Keep enough history to go back past a problem you did not notice at once. A simple pattern works for most businesses: the latest few backups, one from each recent week, and one from each recent month, with the oldest deleted as new ones arrive. Backups kept in your hosting account count in your storage, so move older ones to object storage or your own drive and delete them from the account.

Whatever you keep, label it clearly — the date and the reason, such as "before plugin update" — so the right one is easy to find on a stressful day.

Backing up before risky changes

The most useful backup is the one taken just before something changes. Make one before a WordPress core or plugin update, before a theme switch, before a database migration in an app, and before changing a project's blueprint. It takes a minute from the Backups page and turns a bad afternoon into a quick restore.

For apps deployed from Git, the code itself is already safe in the repository and every release can be rolled back from the dashboard. What still needs a backup is the data: the database and any uploaded files. Keep that distinction in mind and backups stay small and quick.

Testing a restore

A backup you have never restored is a hope, not a plan. A few times a year, take a recent backup, open it on your own computer, and check that the database dumps import and the files are complete. For an important site, restore it to a spare domain or a local copy and click through it. Write down the date and how long it took; that number is your real recovery time, and it is what an auditor or a customer will ask for.

Key takeaways

The short version, for anyone skimming:

• Three copies, two kinds of storage, one off the server.
• Back up hosting projects from the dashboard before every big change, and download one.
• Cloud servers: continuous backup plus object storage exports.
• Back up as often as the work you cannot afford to lose.
• Test a restore at least once, and never keep backups in your web root.