Your CRM contains your business’s most valuable data — customer relationships, deal history, communication records, and workflow configurations built over months or years. Losing this data to server failure, ransomware, accidental deletion, or a failed upgrade can set your business back catastrophically.

A proper backup strategy isn’t optional — it’s the insurance policy that makes every other CRM investment worthwhile. This guide covers what to back up, how to automate it, where to store backups, and how to verify they actually work.

What to Back Up

SuiteCRM has two critical data stores that must both be backed up together:

1. The Database

The MySQL/MariaDB database contains all CRM records — contacts, accounts, opportunities, cases, activities, relationships, workflow definitions, user configurations, and audit logs. This is the most critical component. A corrupted or lost database means all CRM data is gone.

2. The File System

The SuiteCRM application directory contains uploaded files (documents, attachments, images), custom code (custom/ directory with Logic Hooks, custom modules, themes), configuration files (config.php, config_override.php, .htaccess), and cached files and logs. The custom/ directory is especially important — it contains all your customizations that would take weeks to rebuild.

Both must be backed up simultaneously. A database backup without the matching file system (or vice versa) may not restore correctly if customizations reference database structures or uploaded files.

Backup Frequency

Database: Daily at minimum. For high-activity CRMs, consider every 6 or 12 hours. Database dumps are typically small (100MB–2GB) and fast to create.

File system: Daily for uploads and custom/ directory. Weekly full backup of the entire SuiteCRM directory.

Before upgrades: Always create a complete backup (database + full file system) immediately before any SuiteCRM upgrade, plugin installation, or major configuration change.

Automating Backups

Database Backup Script

Create a shell script that runs mysqldump with your database credentials, compresses the output with gzip, and saves it with a timestamped filename. Schedule this with cron to run daily at a low-traffic hour (e.g., 2:00 AM).

Key mysqldump flags: use –single-transaction for InnoDB tables (non-blocking backup), –routines to include stored procedures, and –triggers to include database triggers.

File System Backup Script

Use rsync or tar to create compressed archives of the SuiteCRM directory. Exclude cache/ and log files from daily backups to reduce size. Include the custom/ directory, uploads/ directory, config.php, config_override.php, and .htaccess.

Cron Schedule

Run the database backup script daily at 2:00 AM and the file system backup daily at 2:30 AM. Schedule a full file system backup (including cache) weekly on Sunday at 3:00 AM.

Off-Site Backup Storage

Local backups protect against accidental deletion and application errors. Off-site backups protect against server failure, data center outages, and ransomware.

Amazon S3: Industry-standard object storage. Use the AWS CLI to sync backup files to an S3 bucket after each backup run. Enable versioning and lifecycle policies to retain 30 daily backups and 12 monthly backups.

Google Cloud Storage: Similar to S3 with competitive pricing. Use gsutil for automated transfers.

Separate VPS: Rsync backups to a second server in a different data center. Simple and effective for smaller deployments.

Backblaze B2: Low-cost cloud storage ($5/TB/month). Compatible with S3 APIs for easy integration.

The 3-2-1 rule applies: maintain 3 copies of your data, on 2 different types of storage, with 1 copy off-site.

Backup Retention Policy

Don’t keep backups forever — storage costs add up. A sensible retention policy: keep daily backups for 30 days, weekly backups for 12 weeks, monthly backups for 12 months, and annual backups for 3–5 years.

Automate retention by adding cleanup logic to your backup scripts that deletes files older than the retention period.

Testing Your Backups

An untested backup is not a backup — it’s a hope. Schedule monthly restore tests: create a test server or Docker container, restore the latest database backup and file system backup, verify SuiteCRM loads correctly, spot-check data integrity (record counts, recent records, uploaded files), and document the restore procedure and time.

The first time you need to restore from backup should not be during an actual emergency.

Disaster Recovery Plan

Beyond backups, document your complete recovery procedure: where backups are stored and how to access them, step-by-step restore instructions, expected recovery time (RTO — Recovery Time Objective), maximum acceptable data loss (RPO — Recovery Point Objective), who is responsible for executing the recovery, and contact information for your hosting provider and SuiteCRM support partner.

For businesses where CRM downtime directly impacts revenue, TechEsperto’s support packages include managed backup, monitoring, and guaranteed recovery SLAs. Contact us for details.

Backup Security

Backups contain your most sensitive business data — treat them with the same security as the production system. Encrypt backup files before transferring to off-site storage using GPG or AES-256 encryption. Restrict access to backup storage with IAM policies (S3) or file permissions. Use encrypted transfer protocols (SFTP, SCP, or HTTPS) — never transfer unencrypted backups over the network. Rotate encryption keys annually and store them separately from the backups themselves.

For HIPAA-compliant environments, backup encryption is mandatory. Document your encryption methodology and key management process as part of your compliance documentation. SuiteAssured deployments include security guidance for backup procedures.

Common Backup Mistakes to Avoid

Backing up only the database. Without the file system (uploads, custom code, config files), a database-only restore produces a broken CRM. Always back up both.

Storing backups on the same server. If the server fails, you lose both the CRM and the backups. Always copy backups to a separate location.

Never testing restores. A backup that can’t be restored is worthless. Schedule monthly restore tests on a staging environment.

No retention policy. Keeping every backup forever wastes storage. Keeping too few means you can’t recover from issues discovered weeks later. Follow the 30-day daily / 12-week weekly / 12-month monthly retention schedule.

Ignoring backup monitoring. Cron jobs fail silently. Set up email alerts that notify you when a backup job fails or when backup file sizes are unexpectedly small (indicating incomplete backups).

FAQs

Q1: How often should I back up SuiteCRM? Database: daily minimum (every 6–12 hours for high-activity CRMs). File system: daily for uploads and custom code. Full backup: before any upgrade or major change.

Q2: What’s the easiest backup method? A cron-scheduled shell script running mysqldump + tar, synced to S3 or another cloud storage. This covers 90% of backup needs with minimal setup.

Q3: Should I back up the cache directory? Not for daily backups — cache can be regenerated with Quick Repair and Rebuild. Include cache in weekly full backups as a convenience.

Q4: How do I restore SuiteCRM from backup? Import the database dump with mysql, extract the file system backup to the SuiteCRM directory, update config.php with correct database credentials and site URL, and run Quick Repair and Rebuild.