SQL Server Backup to the Cloud for Small Offices

Why a backup on the same PC is not enough

Many billing, ERP and accounting programs in Indian offices keep their data in SQL Server, often the free Express edition on one office PC. If you already take a daily .bak file (if not, start with how to automate SQL Server Express backups), you have solved half the problem.

The other half is where that file lives. A backup on the same PC, or on a disk plugged into it, is lost along with the database to:

a failed disk or a dead motherboard,
theft of the PC,
fire or water in the office,
ransomware, which locks every drive the PC can reach.

A copy in the cloud is the simplest way to get one copy away from the office, the "1" in the 3-2-1 backup rule. This guide compares the four common ways to do it.

In short: take a proper .bak backup every day, get it off the PC automatically, make sure the cloud copy cannot be deleted from the PC, and check every day that it arrived.

First, what should go to the cloud?

Send backup files, not the live database files.

The .mdf and .ldf files are open all day while SQL Server runs. A copy taken while they are open often will not attach later, even if the copy itself finished without an error.
A .bak file made by BACKUP DATABASE ... WITH CHECKSUM is a consistent snapshot, checked page by page as it is written. That is the file you want away from the office.

Way 1: a sync folder (Google Drive, OneDrive, Dropbox)

Save the .bak files into a folder that Google Drive or OneDrive syncs.

Good: cheap or free, and easy to set up.
Catch: sync folders copy every change, including deletions and encrypted files. If ransomware locks the backup folder, the locked files sync up too, and a deleted folder is deleted in the cloud as well. The trash and version history can undo this only for a limited time, and only if someone notices.
Catch: a 5 GB file uploading through a sync app can take hours. If the PC sleeps or the internet drops, it may never finish, and nothing tells you.
Catch: free storage fills fast. Fourteen daily copies of a 5 GB database need about 70 GB.

It is better than nothing, but it is not a safe off-site copy. More in Google Drive, pen drive or online backup.

Way 2: SQL Server's own "backup to URL"

SQL Server can write a backup straight to cloud storage instead of a local file: to Microsoft Azure Blob Storage, and on SQL Server 2022 and later, also to S3-compatible storage. Check that your version and edition support the storage you pick.

Good: no extra software; the backup goes straight to the cloud.
Catch: you need a cloud account, a storage container, and credentials stored inside SQL Server. This is a job for someone comfortable with the cloud console.
Catch: on Express there is no SQL Server Agent, so you still need a script and Task Scheduler to run it every night.
Catch: the backup only exists in the cloud unless you also take a local one. If the internet is down at backup time, there is no backup that night.
Catch: cloud bills come in dollars, and you pay for storage and for downloading the data when you restore.

It is a good fit for a company with an IT person who already uses Azure or AWS.

Way 3: a script that uploads the .bak file

Keep the local backup, then add a step that copies new .bak files to cloud storage. Free tools such as rclone or the AWS command line can do this from a scheduled task. For example, with rclone set up for your storage:

rclone copy D:\SQLBackup mycloud:office-backups/sql

This uploads any backup file that is not in the cloud yet, so a night the upload missed is caught up the next day.

Good: you keep a local copy for quick restores and get a cloud copy. Storage in an India region (AWS Mumbai or Hyderabad, Azure Central India) is a matter of choosing it.
Catch: the upload keys sit on the PC. If ransomware or an attacker finds keys that can delete, they can wipe your cloud copies too. Use keys that can only add files, and turn on the storage's lock feature (S3 Object Lock, or immutable storage on Azure).
Catch: Express cannot compress backups, so you upload the full size every day. On a 20 Mbps upload line, 5 GB takes about 35 minutes.
Catch: someone has to read the log. A changed password or a full account stops the upload, and the script keeps "running" without anything arriving.

Way 4: a managed backup service

A backup service installs a small program on the PC that takes the SQL Server backup, packs and encrypts it, uploads it, and tells you every day whether it worked.

Good: no scripts, cloud console or keys to look after. A good service locks the copies so nothing on your PC can delete them, keeps older copies, and checks that they restore.
Catch: a monthly fee. Check where the data is stored, whether copies are locked, and whether someone actually watches for failures.

Quick comparison

	Sync folder	Backup to URL	Upload script	Managed service
Setup effort	Low	High	Medium to high	Low
Local copy too	Yes	Only if you add one	Yes	Depends on the service
Safe from ransomware on the PC	No	Only with locked storage	Only with locked storage and add-only keys	Yes, if copies are locked
Tells you when it fails	No	No	Only if you build it	Yes
Monthly cost	Free to low	Pay per GB, in dollars	Pay per GB, in dollars	Fee by space used

Mistakes that leave you exposed

Copying the .mdf file instead of a .bak. It looks like a backup until the day it will not attach.
One copy, overwritten every night. If data went wrong last week, last night's copy holds the same mistake. Keep daily copies for two weeks, then weekly and monthly ones.
Delete rights on the PC. If the PC can delete the cloud copies, so can ransomware running on that PC.
Never checking the upload. "The task ran" is not "the file arrived". Check the newest file in the cloud, not the log on the PC.
Never testing a restore. Every few months, download a copy and restore it on another PC under a new name. See how to check your backup will really restore.

Common questions

How much internet speed do I need?

Divide the backup size by your upload speed. A 5 GB backup takes about 35 minutes on 20 Mbps and about 7 minutes on 100 Mbps. Compressing the backup before upload cuts this a lot; business data often packs to a fifth of its size or less.

Should the cloud copy be encrypted?

Yes. Encrypt the file on your PC before it leaves, so nobody at the storage company or on the way can read it. Keep the password or key somewhere safe away from the PC, or you will not be able to restore.

Is it a problem if my data is stored outside India?

For most small businesses there is no general rule against it, though some fields, such as payments, have their own rules on where data is kept. Many owners prefer their accounts and customer data to stay in India. Most large cloud providers let you choose an India region.

Can I back up while people are working?

Yes. SQL Server takes a full backup while the database is in use. Run it after office hours anyway, so the backup and the upload do not slow the PC during the day.

How JS1 Vault does it

JS1 Vault is a managed backup made for Indian offices that run SQL Server based ERP and billing software, on Express or any other edition:

It backs up each database every evening with checksums and checks every copy with RESTORE VERIFYONLY. No SQL Server Agent or scripts are needed.
It packs and encrypts each copy on your PC, then uploads it to storage in India, resuming by itself if the internet drops.
Copies are locked: nothing on your PC can change or delete them. Database copies are kept daily for 14 days, then one a week and one a month as far back as your plan's space allows.
Once a month a copy is restored on your PC under a new name and opened, to prove it really comes back.
An email every evening says all is safe, or tells you and us at once when something is wrong.

The same program also backs up your folders and files, including Tally data.

See how JS1 Vault works and start a free trial.

← Back to all posts