You have heard that Website Backup is important multiple times. And yet, talking to developers and sysadmins even years into their careers, the story is almost always the same: backups were set up once, never tested, and when something broke, the restore either didn’t work or nobody knew how to trigger it in the first place.
A server update goes wrong. A misconfigured cron job overwrites a database. A client accidentally deletes their WordPress plugin folder. In every one of these cases, the difference between a five-minute restore and a full-day rebuild is whether you actually have a working backup strategy in place.
This guide is about ServerAvatar's backup system, but more importantly, it’s about thinking through your disaster recovery approach before you are staring at a broken site at two in the morning.
We will cover the three backup types ServerAvatar offers, how to actually use them in practice, what restore looks like, and the operational habits that make backups reliable rather than just theoretically existent. If you’re running applications on ServerAvatar and haven’t touched the backup system yet, this is the guide that will get you set up properly.
TL;DR
- ServerAvatar offers three distinct backup types: File System, Application, and Database
- Instant Backups are for right-now; Scheduled Backups handle recurring protection automatically
- Archive Backups let you recover backups from applications you have deleted
- Cross-server restore is available, you can pull a backup from one server and spin it up on another
- Cloud storage integration (Google Drive, Amazon S3, S3 Compatible Storage, Wasabi) keeps your backups off-server
- Retention policies determine how long backups live, set these consciously, not at the default
- Test your restores. A backup you haven’t verified is a liability, not an asset
Why Website Backups Should Be Part of Your Disaster Recovery Plan
A backup is simply a copy of your data. Disaster recovery is the larger process of using that copy to recover your website after an incident. That distinction matters.
Imagine a WordPress application loses its database after an unexpected server problem. Having a backup from three months ago technically means the site has a backup, but it may not be sufficient to recover recent orders and customer information.
Similarly, having hundreds of backup files doesn’t help much if:
- The newest backup is incomplete.
- The database wasn’t included.
- Backup copies stored on the same server hosting the website.
- Nobody knows which backup should be restored.
- The restoration process has never been tested.
- Backup retention is too short.
- The backup exists but cannot be accessed during an outage.
A useful disaster recovery strategy therefore needs to answer three questions:
- What needs to be backed up?
- How often should it be backed up?
- How quickly can the website be restored?
These questions form the foundation of a reliable backup plan.
Understanding Backup Types in ServerAvatar
Before you create your first backup, it helps to understand what you’re actually backing up. ServerAvatar separates backups into three types, and choosing the right one depends on your recovery goal.
File System Backup
This captures only the files belonging to your application, your code, uploads, configuration files, everything sitting in the application directory. No database is included.
You’d reach for this when you know your application database is safe but something happened to the files themselves, maybe a deployment went sideways and overwrote the wrong directory, or a malicious script got dropped into your uploads folder.
Application Backup
This is the comprehensive option. It backs up your application files and the associated database together as a unit. If you want one backup that represents the complete state of your site at a given moment, this is the choice.
For most WordPress, Laravel, or Node.js sites in production, Application backup is what you default to.
Database Backup
Some workloads change files frequently but keep databases relatively stable. Others modify the database constantly but rarely touch files. Database-only backup lets you capture just the database on its own schedule, separate from how often you snapshot the file system.
You might run database backups hourly while file system backups run daily. That’s a valid and sensible approach.
Choosing the Right Backup Type
The best backup type depends on what you need to recover:
- Need to restore application files? Use a File System Backup.
- Need files and database together? Use an Application Backup.
- Need to protect frequently changing database data? Use a Database Backup.
- Need different backup schedules for files and databases? Use separate File System and Database Backups.
Understanding Backup File Formats
Server backups can contain different types of data, so the format used for the backup also matters. Common formats include:
- .tar – Creates an archive containing multiple files without compression.
- .tar.gz – Creates a compressed archive, reducing the amount of storage required for application files.
- .sql – Stores a database dump as plain SQL statements.
- .sql.gz – Stores a compressed SQL database dump, making it smaller and easier to transfer.
For most website backup scenarios:
- Use .tar.gz for application or file backups.
- Use .sql.gz for database backups.
Why Compression Matters
Compression can make a noticeable difference when you are storing or transferring backups. Compressed backups can:
- Require less disk space
- Reduce storage costs
- Take less time to transfer
- Make remote backup storage more efficient
- Reduce the amount of data that needs to move between your server and backup destination
Combining the right backup type, schedule, and file format helps create a reliable disaster recovery plan, rather than simply storing backups without a clear recovery strategy.
Read Full Article: https://serveravatar.com/website-backup
