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

  1. Start → Administration & SetupUtilityBackup.
  2. Pick the datacenter and the destination folder.
  3. Click Backup Now. Wait for "Backup completed" — large databases take a few minutes.
  4. For a daily schedule, click Schedule. Pick a time outside business hours (e.g. 23:30).
  5. Set retention — Keep last 14 daily is a common safe default; for larger shops set Keep last 30 daily + 12 monthly.
  6. Tick Email on failure and enter an admin email so you find out if backups stop.
  7. Save the schedule. SSM (the Suite Services Manager) picks it up and runs the backup unattended.
  8. 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.