MSSQL Backup Strategy on a Windows VPS: Full, Differential, and Log Backups
Back up SQL Server on a Windows VPS with a practical strategy for full, differential, and log backups, off-server copies, retention, and restore testing.

On this page
- In short
- Quick verdict
- What we tested on Raff
- Why backup strategy matters
- RTO and RPO: decide before designing backups
- The practical 3-3-2 backup rule
- Recovery models: choose first
- SQL Server Express vs Standard / Enterprise
- Step 1 - Confirm SQL Server is installed
- Step 2 - Confirm SQL Server version
- Step 3 - Create the backup directory
- Step 4 - Take a FULL backup
- Step 5 - Take a DIFFERENTIAL backup
- Step 6 - Take a LOG backup
- Step 7 - Confirm backup files exist
- Step 8 - Verify the backup file
- Recommended production schedule
- Use timestamped backup files in production
- Automating backups on SQL Server Express
- Automating backups on SQL Server Standard or Enterprise
- Off-server backup is not optional
- Retention policy
- Restore sequence
- Common mistakes
- What Raff recommends
- Tested on
- What's next
- Sources
Don't have a Windows Server yet?
Deploy Windows Server 2019/2022/2025 in ~2 minutes. 6-month evaluation licence included.
In short
A production MSSQL backup strategy on a Windows VPS should include full backups, differential backups, transaction log backups for databases in FULL recovery model, off-server copies, retention rules, and restore testing. For many SMB workloads, a practical starting point is daily FULL backups, DIFFERENTIAL backups every few hours, and LOG backups every 15 minutes when point-in-time recovery matters. The most important rule: an untested backup is not a real backup.
Quick verdict
| Situation | Recommended backup approach |
|---|---|
| Production database with important transactions | FULL + DIFFERENTIAL + LOG backups |
| Database in FULL recovery model | Take LOG backups regularly |
| Database in SIMPLE recovery model | FULL + DIFFERENTIAL backups only |
| Small test or dev database | FULL backup may be enough |
| Business-critical SQL workload | Copy backups off-server and test restores |
| SQL Server Express | Use Task Scheduler + sqlcmd; SQL Server Agent is not included |
| SQL Server Standard / Enterprise | Use SQL Server Agent jobs where available |
The goal is not just to create .bak files. The goal is to know how much data you can lose, how fast you can recover, and whether the backup actually restores.
What we tested on Raff
We tested the backup workflow on a Raff Windows VPS running Windows Server 2025 Datacenter Evaluation and SQL Server 2025 Express.

Test environment:
| Item | Value |
|---|---|
| Provider | Raff Technologies |
| OS | Windows Server 2025 Datacenter Evaluation |
| SQL Server | SQL Server 2025 Express |
| Instance | SQLEXPRESS |
| SQL version | 17.0.1000.7, RTM |
| Database | RaffBackupTest |
| Test date | 2026-05-26 |
| Tester | Serdar Tekin |
We verified:
- SQL Server 2025 Express installation
- SQL Server service status
sqlcmdcommand-line access- SQL Server version query
- Sample database creation
- Recovery model check
- FULL recovery model configuration
- Backup folder creation
- FULL backup
- DIFFERENTIAL backup
- LOG backup
- Backup files written to disk
RESTORE VERIFYONLYbackup validation
We tested with SQL Server Express, so some production features differ. SQL Server Agent is not included in Express, and backup compression was not supported in our Express test. For Standard or Enterprise editions, SQL Server Agent and backup compression may be available depending on edition and configuration.
Why backup strategy matters
A SQL Server database can fail in several ways:
- Accidental delete
- Bad application update
- Corrupt data
- Ransomware
- Disk issue
- Failed migration
- Human error
- Broken Windows Update or software change
- VPS-level incident
- Application bug writing bad data
A local backup protects against some database-level mistakes. It does not protect against every risk.
A proper strategy needs:
- Backups created on schedule
- Backups copied away from the server
- Backups retained for the right amount of time
- Restore tests
- Clear RTO and RPO targets
RTO and RPO: decide before designing backups
Before choosing a schedule, define two things.
| Term | Meaning | Example |
|---|---|---|
| RTO | Recovery Time Objective: how fast you need to restore service | Back online within 1 hour |
| RPO | Recovery Point Objective: how much data you can lose | Lose no more than 15 minutes of data |
If your business can only lose 15 minutes of transactions, you need transaction log backups around every 15 minutes.
If your business can tolerate losing one day of changes, a daily full backup may be enough.
Do not design backup schedules blindly. Start with the business risk.
The practical 3-3-2 backup rule
For many SMB SQL Server workloads, use this pattern:
| Layer | Meaning |
|---|---|
| 3 backup levels | FULL, DIFFERENTIAL, and LOG backups |
| 3 copies of data | Production database, local backup, off-server backup |
| 2 storage locations | Local VPS storage plus external storage/provider |
A practical example:
| Backup type | Frequency | Purpose |
|---|---|---|
| FULL | Daily | Complete restore baseline |
| DIFFERENTIAL | Every 4 hours | Faster restore with fewer log files |
| LOG | Every 15 minutes | Point-in-time recovery |
| Off-server copy | Within 30 minutes of backup creation | Protection from server loss or deletion |
This is a starting point. Adjust it based on your RTO, RPO, database size, and workload.
Recovery models: choose first
SQL Server recovery model controls whether transaction log backups are meaningful.
Check current recovery models:
sqlSELECT name, recovery_model_desc
FROM sys.databases;
| Recovery model | Use for | Backup pattern |
|---|---|---|
| FULL | Production OLTP, accounting, ERP, financial systems | FULL + DIFFERENTIAL + LOG |
| SIMPLE | Dev/test, reporting, low-risk databases | FULL + DIFFERENTIAL |
| BULK_LOGGED | Special bulk-load workflows | FULL + DIFFERENTIAL + LOG, with caveats |
In our test, we created a sample database and checked its recovery model.

For point-in-time recovery, set the database to FULL recovery model:
sqlALTER DATABASE RaffBackupTest SET RECOVERY FULL;
Then confirm:
sqlSELECT name, recovery_model_desc
FROM sys.databases
WHERE name = 'RaffBackupTest';

Important: after switching to FULL recovery model, take a FULL backup to start the log backup chain.
SQL Server Express vs Standard / Enterprise
SQL Server Express is useful for small workloads and testing, but it has limitations that affect backup automation.
| Feature | SQL Server Express | SQL Server Standard / Enterprise |
|---|---|---|
| Database backups | Yes | Yes |
| FULL / DIFF / LOG backups | Yes, depending on recovery model | Yes |
| SQL Server Agent | No | Yes |
| Scheduled backup jobs inside SQL Server Agent | No | Yes |
| Task Scheduler + sqlcmd | Yes | Yes |
| Backup compression | Not supported in our Express test | Often available, edition-dependent |
| Good for this article test | Yes | Yes |
For SQL Server Express, use Windows Task Scheduler with sqlcmd or another automation tool.
For SQL Server Standard or Enterprise, use SQL Server Agent jobs.
Step 1 - Confirm SQL Server is installed
First, check whether a normal SQL Server instance is installed.
Run PowerShell as Administrator:
powershellGet-Service | Where-Object {$_.Name -like "MSSQL*"} | Select-Object Name, Status, DisplayName
After installing SQL Server 2025 Express, our test server showed the SQLEXPRESS instance running.

We also confirmed that sqlcmd was installed:
powershellsqlcmd -?
If sqlcmd is not recognized, install the SQL Server command-line tools or use SSMS for manual testing.
Step 2 - Confirm SQL Server version
Check the SQL Server version:
powershellsqlcmd -S localhost\SQLEXPRESS -E -C -Q "SELECT @@VERSION AS SQLVersion;"
The -C flag tells sqlcmd to trust the server certificate. With newer ODBC drivers, encrypted connections are common by default, and local test instances may use certificates that are not trusted by the client.
In our test, SQL Server 2025 Express was installed successfully.
Step 3 - Create the backup directory
Create a local backup directory:
powershellNew-Item -ItemType Directory -Path 'C:\SQL\Backups' -Force
Grant SQL Server Express access to the folder:
powershellicacls 'C:\SQL\Backups' /grant 'NT SERVICE\MSSQL$SQLEXPRESS:(OI)(CI)F'
Verify the folder exists:
powershellGet-ChildItem C:\SQL

For production, do not rely only on the system drive. If possible, use a separate data or backup volume, then copy backups off-server.
Step 4 - Take a FULL backup
A FULL backup is the foundation of the restore chain.
For SQL Server Express, we used this command without COMPRESSION because Express did not support backup compression in our test:
powershellsqlcmd -S localhost\SQLEXPRESS -E -C -Q "BACKUP DATABASE [RaffBackupTest] TO DISK = N'C:\SQL\Backups\RaffBackupTest_FULL.bak' WITH INIT, CHECKSUM, STATS = 10;"

For editions that support backup compression, you can use:
sqlBACKUP DATABASE [YourDB]
TO DISK = N'C:\SQL\Backups\YourDB_FULL.bak'
WITH INIT, COMPRESSION, CHECKSUM, STATS = 10;
Use CHECKSUM whenever possible. It helps detect backup corruption during the backup process.
Use INIT when you want to overwrite the existing backup file instead of appending to it.
For production, prefer timestamped file names instead of overwriting the same file every day.
Step 5 - Take a DIFFERENTIAL backup
A DIFFERENTIAL backup captures changes since the most recent FULL backup.
Run:
powershellsqlcmd -S localhost\SQLEXPRESS -E -C -Q "BACKUP DATABASE [RaffBackupTest] TO DISK = N'C:\SQL\Backups\RaffBackupTest_DIFF.bak' WITH DIFFERENTIAL, INIT, CHECKSUM, STATS = 10;"

Differential backups reduce restore complexity.
Without differentials, a restore may require yesterday's full backup plus many transaction log files. With differentials, you restore the latest full backup, the latest differential, then only the log files after that differential.
Step 6 - Take a LOG backup
For a database in FULL recovery model, transaction log backups are required for point-in-time recovery.
Run:
powershellsqlcmd -S localhost\SQLEXPRESS -E -C -Q "BACKUP LOG [RaffBackupTest] TO DISK = N'C:\SQL\Backups\RaffBackupTest_LOG.trn' WITH INIT, CHECKSUM, STATS = 10;"

If you use FULL recovery model but never take log backups, the transaction log can keep growing until it fills the disk.
That is one of the most common SQL Server backup mistakes.
Step 7 - Confirm backup files exist
After running FULL, DIFFERENTIAL, and LOG backups, check the backup folder:
powershellGet-ChildItem 'C:\SQL\Backups' | Select-Object Name, Length, LastWriteTime
You should see:
textRaffBackupTest_FULL.bak
RaffBackupTest_DIFF.bak
RaffBackupTest_LOG.trn

The exact file sizes and timestamps will differ.
What matters:
| File | Expected |
|---|---|
.bak full backup | Present and larger than 0 bytes |
.bak differential backup | Present and larger than 0 bytes |
.trn log backup | Present and larger than 0 bytes |
| Timestamp | Matches the backup test window |
Step 8 - Verify the backup file
A backup file existing on disk is not enough. Verify that SQL Server can read it.
Run:
powershellsqlcmd -S localhost\SQLEXPRESS -E -C -Q "RESTORE VERIFYONLY FROM DISK = N'C:\SQL\Backups\RaffBackupTest_FULL.bak' WITH CHECKSUM;"
Expected result:
textThe backup set on file 1 is valid.

RESTORE VERIFYONLY does not replace a real restore drill, but it is a useful first check.
For production, perform periodic restore tests to a separate database or separate test server.
Recommended production schedule
For a production database in FULL recovery model, use this as a starting point:
| Backup type | Frequency | Purpose |
|---|---|---|
| FULL | Daily, usually overnight | Complete restore baseline |
| DIFFERENTIAL | Every 4 hours during business hours | Faster restore |
| LOG | Every 15 minutes | Point-in-time recovery |
| Off-server copy | Within 30 minutes | Protection from local server loss |
| Restore test | Quarterly | Prove the backup actually works |
Adjust the schedule for your workload.
If the database changes rarely, you may not need aggressive log backups.
If the database handles orders, accounting, payments, or customer operations, 15-minute log backups may be appropriate.
Use timestamped backup files in production
Our test used fixed file names for clarity:
textRaffBackupTest_FULL.bak
RaffBackupTest_DIFF.bak
RaffBackupTest_LOG.trn
For production, use timestamped file names.
Example naming pattern:
textYourDB_FULL_20260526_020000.bak
YourDB_DIFF_20260526_100000.bak
YourDB_LOG_20260526_101500.trn
This prevents accidental overwrite and makes restore sequencing easier.
Automating backups on SQL Server Express
SQL Server Express does not include SQL Server Agent.
Use Windows Task Scheduler with sqlcmd.
Example full backup command:
powershellsqlcmd -S localhost\SQLEXPRESS -E -C -Q "BACKUP DATABASE [YourDB] TO DISK = N'C:\SQL\Backups\YourDB_FULL.bak' WITH INIT, CHECKSUM, STATS = 10;"
Create separate scheduled tasks for:
- FULL backup
- DIFFERENTIAL backup
- LOG backup
- Off-server copy
- Cleanup
For SQL Server Standard or Enterprise, use SQL Server Agent jobs instead.
Automating backups on SQL Server Standard or Enterprise
For paid SQL Server editions with SQL Server Agent:
- Open SQL Server Management Studio.
- Expand SQL Server Agent.
- Create a new Job.
- Add a T-SQL backup step.
- Add a schedule.
- Configure notifications.
- Test the job manually.
- Review job history.
Use separate jobs or separate job steps for FULL, DIFFERENTIAL, and LOG backups.
Off-server backup is not optional
Local backups are useful, but they are not enough.
Local backups do not protect you from:
- VPS deletion
- Compromised administrator account
- Ransomware deleting backup files
- Disk failure
- Accidental cleanup
- Region/provider-level incident
Copy backups to another location.
Options include:
- Object storage such as S3-compatible storage
- Backblaze B2
- Cloudflare R2
- Another backup server
- Managed backup storage
- Separate Raff storage option, if available for your plan
A simple pattern:
powershellrclone copy 'C:\SQL\Backups\' 'remote:sql-backups/' --transfers 4
Schedule the off-server copy after each backup window.
Retention policy
Do not keep backups forever on the VPS. You will fill the disk.
A practical SMB retention policy:
| Backup type | Keep locally | Keep off-server |
|---|---|---|
| FULL | 7 days | 30 days |
| DIFFERENTIAL | 3 days | 7 days |
| LOG | 24 hours | 7 days |
| Monthly FULL | Optional | 12 months |
Retention depends on compliance, storage cost, and business need.
For production, document the retention policy and verify cleanup does not delete files needed for restore.
Restore sequence
A typical restore sequence for FULL recovery model:
- Restore the most recent FULL backup with
NORECOVERY. - Restore the most recent DIFFERENTIAL backup with
NORECOVERY. - Restore LOG backups in order with
NORECOVERY. - Restore the final LOG with
RECOVERY, or runRESTORE DATABASE ... WITH RECOVERY.
Example:
sqlRESTORE DATABASE [YourDB_RestoreTest]
FROM DISK = 'D:\BackupCopy\YourDB_FULL.bak'
WITH NORECOVERY, REPLACE;
RESTORE DATABASE [YourDB_RestoreTest]
FROM DISK = 'D:\BackupCopy\YourDB_DIFF.bak'
WITH NORECOVERY;
RESTORE LOG [YourDB_RestoreTest]
FROM DISK = 'D:\BackupCopy\YourDB_LOG_001.trn'
WITH NORECOVERY;
RESTORE DATABASE [YourDB_RestoreTest] WITH RECOVERY;
After restore, run:
sqlDBCC CHECKDB('YourDB_RestoreTest') WITH NO_INFOMSGS;
Document how long the restore took. That is your real RTO.
Common mistakes
No off-server backup
If backups only live on the same VPS, they can disappear with the server. Copy them somewhere else.
FULL recovery model without LOG backups
This causes transaction log growth and can eventually fill the disk. If you use FULL recovery model, take log backups.
Never testing restores
A backup strategy is incomplete until you prove restore works.
Backing up to the same disk as the database
It is better than nothing, but not enough. Use a separate volume or off-server location where possible.
Assuming SQL Server Express has SQL Server Agent
It does not. Use Task Scheduler and sqlcmd for Express.
Copying backup scripts without checking edition support
In our SQL Server 2025 Express test, BACKUP ... WITH COMPRESSION was not supported. Use compression only on SQL Server editions that support it.
Overwriting the same file forever
Fixed file names are fine for a lab. Production should use timestamped files and retention rules.
What Raff recommends
For production SQL Server workloads on a Windows VPS, Raff recommends:
- Choose the right recovery model.
- Use FULL recovery for business-critical databases.
- Take regular FULL, DIFFERENTIAL, and LOG backups.
- Copy backups off-server.
- Use
CHECKSUM. - Verify backups with
RESTORE VERIFYONLY. - Run real restore drills.
- Monitor disk usage.
- Document RTO and RPO.
- Review the backup schedule after application or workload changes.
A backup is only useful if you can restore it in time.
Tested on
Tested on Raff Windows VPS, Windows Server 2025 Datacenter Evaluation, SQL Server 2025 Express, SQLEXPRESS instance, SQL Server version 17.0.1000.7 RTM, 2026-05-26. We installed SQL Server Express, verified the SQL service and sqlcmd, created the RaffBackupTest database, set FULL recovery model, created FULL, DIFFERENTIAL, and LOG backups, confirmed backup files on disk, and validated the full backup with RESTORE VERIFYONLY. Tester: Serdar Tekin.
What's next
- Install MSSQL Server 2025 on a Windows VPS - install and prepare SQL Server on a Raff Windows VPS
- Windows Update Strategy on Production Servers - patch Windows Server safely with snapshots and maintenance windows
- Configure Windows Firewall on a Windows VPS - review inbound rules for SQL Server, RDP, and IIS
- Windows Server Hardening Checklist - secure a Windows Server VPS before production
- Raff Windows VPS - deploy a Windows Server VPS for SQL Server, IIS, business apps, and remote administration
Sources
- Microsoft Learn - Back up and restore of SQL Server databases
- Microsoft Learn - Recovery models
- Microsoft Learn - BACKUP Transact-SQL
- Microsoft Learn - RESTORE VERIFYONLY Transact-SQL
- Microsoft Learn - SQL Server editions and supported features
- Date last verified: 2026-05-26
Related articles
How to Set Up SMB over QUIC on Windows Server 2025 with a Let's Encrypt Certificate (No VPN Needed)
Windows Server 2025 brings SMB over QUIC to Standard and Datacenter editions, not just Azure Edition. We walk through the full setup: File Server role, free Let's Encrypt certificate via win-acme, SMB binding, and a Windows 11 client connection. Tested live on a Raff Server in Virginia.
How to Host ASP.NET Core 10 on IIS — Windows Server Guide (2026)
Step-by-step guide to hosting ASP.NET Core 10 apps on IIS on a Windows Server VPS. Covers IIS install, .NET 10 Hosting Bundle, app pool config, deployment, and common errors. Tested end-to-end on Raff.
Install SQL Server 2025 on a Windows Server VPS (Standard Developer, 2026 Guide)
End-to-end install guide for SQL Server 2025 Standard Developer on a Windows Server VPS. Covers winget setup, Custom wizard, tempdb, firewall, and post-install CU application.