How to Take a Backup
Manual and scheduled database backups.
Purpose
Take a manual backup of the ZN ERP database, and set up an automatic daily schedule so you never lose more than a day of work. Backups are cheap; lost data is not — even small shops should have at least one local schedule and one off-site copy.
Before you begin
- A folder with enough free disk space (a year of backups can run into many GB — allow at least 50× your current database size).
- Ideally, an external / network drive separate from the SQL data drive.
- Admin access to Utility.
- For off-site copies: an OneDrive / Google Drive / S3 bucket or similar.
Steps
- Start → Administration & Setup → Utility → Backup.
- Pick the datacenter and the destination folder.
- Click Backup Now. Wait for "Backup completed" — large databases take a few minutes.
- For a daily schedule, click Schedule. Pick a time outside business hours (e.g. 23:30).
- Set retention — Keep last 14 daily is a common safe default; for larger shops set Keep last 30 daily + 12 monthly.
- Tick Email on failure and enter an admin email so you find out if backups stop.
- Save the schedule. SSM (the Suite Services Manager) picks it up and runs the backup unattended.
- Add a second target — either a network drive or cloud sync folder — so the backup leaves the SQL server box.
What success looks like
- A timestamped .bak file (or .zbk depending on your build) appears in the destination folder every night.
- Backup History on the Utility screen lists each successful run.
- A test restore (see How to Restore a Backup) onto a test datacenter completes without errors.
Troubleshooting
- "Path not accessible" error on Backup Now.
- The SQL Server service account does not have write permission to the destination folder. Grant the service account (often NT Service\MSSQLSERVER) Modify rights, or pick a folder under C:\ProgramData\.
- Schedule does not run.
- SSM is not running. Open Services and start Suite Services Manager; set startup type to Automatic.
- Backup file is much smaller than expected.
- Compression is on — this is fine, the restore will still work. To confirm, run a test restore.
- Disk fills up.
- Retention setting is too generous. Reduce Keep last N on the schedule and re-save; old files are pruned on the next run.
Tips
- Backups on the same drive as the database protect against corruption only — not against drive failure. Copy backups to a different drive or to cloud storage as well.
- Restore-test a backup once a month onto a test datacenter — an untested backup is a guess.
- Document the backup destinations and the restore procedure in your team's shared notes — the person who knows is rarely the person on shift when disaster strikes.
- Warning. Cloud-sync folders are not a substitute for a backup — they propagate corruption / accidental deletes. Use them as the destination for the backup file, not as the backup mechanism.