![\"The](\"https:\/\/www.scalahosting.com\/blog\/wp-content\/uploads\/2026\/08\/The-Complete-Guide-to-Website-Backup-Recovery-and-Disaster-Recovery-1140x513-1.webp\")
<\/figure>\n\n\n\nThe three terms are often treated as synonyms. They aren’t. Using them interchangeably leads to strategies with gaps – plans that look complete on paper but leave a category of failure entirely unaddressed.<\/p>\n\n\n\n
Backup<\/strong> is the process of copying your website’s files, databases, and emails to a separate storage location on an automated schedule. A backup answers one question: if data is deleted, overwritten, or corrupted, can you get it back? The answer depends on when the last backup ran, what it captured, and how far back your restore points go.<\/p>\n\n\n\n Recovery<\/strong> is the act of restoring that data. You might recover a single deleted file, a database table dropped accidentally, or an entire account after a site compromise. Recovery is only ever as good as the backup it reads from: if the most recent backup is twelve hours old, recovery means accepting twelve hours of lost changes.<\/p>\n\n\n\n Disaster recovery<\/strong> is a different conversation entirely. It addresses scenarios where the server itself no longer exists due to a hardware failure, a lost cloud virtual machine without a recoverable state, or a catastrophic data center incident. Disaster recovery means rebuilding an entire hosting environment from offsite backups onto fresh hardware. The server isn’t being restored. It’s being recreated.<\/p>\n\n\n\n Understanding all three matters is crucial because a strategy that’s strong in one area can still have serious gaps in others. Daily backups with no offsite copy provide no protection if the server is down. Offsite backups with a short retention period are no good when a compromise dates back several weeks.<\/p>\n\n\n\n Most backup conversations start and end with a single question: Is there a backup? The more useful questions are: where is it, how many separate copies exist, and is there any scenario in which all of them could be lost simultaneously?<\/p>\n\n\n\n The 3-2-1 rule provides a framework for those questions. Coined by photographer and digital asset management expert Peter Krogh <\/em>and since adopted as a formal recommendation by security organizations, including the US Cybersecurity and Infrastructure Security Agency, the strategy has three components:<\/p>\n\n\n\n Applied to a hosting account: your live website is copy one. A backup on the same server is the second copy – easy to access, but sharing the fate of the primary hardware. A backup on a remote server or cloud storage account you control independently is copy number three, stored in a location with an entirely separate failure mode.<\/p>\n\n\n\n The reason two storage types matter: different failure modes affect different systems. A ransomware attack that encrypts your server can also encrypt anything directly mounted to it. An offsite copy on a storage account with separate credentials is unaffected – a different system, a different attack surface.<\/p>\n\n\n\n The reason one copy must be stored offsite is simple. Hardware problems and data center outages aren’t always quick to resolve. If all three copies live on the same physical infrastructure, you don’t have three copies – you have one copy with two mirrors and a single point of failure.<\/p>\n\n\n\n What the 3-2-1 rule doesn’t cover is frequency and retention – how often to take backups and how long to keep them. That depends on how quickly your site’s data changes and how much of it you can afford to lose. The rule tells you where to put your backups. The retention strategy is what you build on top of it.<\/p>\n\n\n\n ScalaHosting customers have access to a built-in backup system that runs on a schedule and protects three things together: files, databases, and email. These aren’t separate operations – a single backup run captures the document root that makes up your website, the databases those files depend on, and the mailbox data associated with the account. Restoring from that backup brings all three back as a coherent whole.<\/p>\n\n\n\n The mechanism underneath is rsync<\/strong>, a file-synchronization tool that transfers only what has changed since the last backup. On a large site, this keeps backup windows short and storage-efficient – a full incremental run against a mostly-unchanged file set takes a fraction of the time a fresh copy would.<\/p>\n\n\n\n Backups can run to up to four destinations simultaneously, each operating independently:<\/p>\n\n\n\n Each destination operates independently. A slow upload to S3 doesn’t delay the local backup. A temporary outage on the remote server doesn’t stop the other destinations from running. The system keeps going with whatever is available, and logs clearly when a destination was unreachable rather than silently skipping it.<\/p>\n\n\n\n All of this is managed through SPanel<\/a>, ScalaHosting\u2019s hosting control panel. Feature availability can vary by hosting environment, but SPanel is used across ScalaHosting shared hosting and managed VPS services<\/a>.<\/p>\n\n\n\n One operational detail worth knowing: the backup process is CPU-throttled. A governor limits how much processor time it can consume, ensuring live websites remain responsive during a full backup run. If you’ve used a shared environment where the overnight backup makes the site sluggish for hours, this is the design decision that prevents that.<\/p>\n\n\n\n \ufeffSPanel\u2019s backup system is designed as more than a scheduled copy of website files. It supports multiple backup destinations, independent retention schedules, CPU-throttled backup runs, MariaDB point-in-time recovery, custom manual backups, restore-point locking, database\/account exclusions, and full-server disaster recovery. That combination lets website owners recover from small mistakes, database-level incidents, and full infrastructure loss using the same control-panel ecosystem.<\/p>\n\n\n\n Running a backup is one decision. How long you keep it – and how many restore points you maintain within that window – is another. Retention determines how far back you can go, and how precisely you can target a specific moment in time.<\/p>\n\n\n\n Four retention tiers give you independent control over each layer:<\/p>\n\n\n\n Each destination can run on a different schedule. Local storage is fast and cheap to use frequently – hourly backups there give you fine-grained recovery for recent events. Remote or cloud storage may have different cost profiles, making daily or weekly backups the more practical choice for offsite protection.<\/p>\n\n\n\n Here’s what a sensible configuration looks like for a live ecommerce store: hourly backups during business hours retained for 24 hours, daily backups retained for a week, the Sunday backup retained for a month, and the first-of-the-month backup retained for six months. That gives fine-grained coverage for recent problems and progressively coarser coverage for older ones – which matches how recovery scenarios actually play out in practice.<\/p>\n\n\n\n The four backup destinations are not alternatives to one another. Running more than one simultaneously is the recommended approach – each destination has its own failure mode, and a backup that survives one scenario may not survive another.<\/p>\n\n\n\n Local backups are stored in a dedicated directory on the same server that hosts your live site. They’re the fastest restore option – no network transfer, just reading from the local disk. For recovering a deleted file, reverting a broken configuration, or undoing an accidental database change, local backups are the right tool. The trade-off is obvious: a local backup shares the same hardware as the production site. Server loss means local backup loss.<\/p>\n\n\n\n Remote backups send data to a separate server over SSH. SPanel handles key-based authentication automatically during setup – no manual key exchange, no passwords stored in configuration files. The receiving server needs SSH access and enough storage capacity; beyond that, it can be any machine you operate. The result is a true offsite copy: if your primary server is knocked offline, the remote backups remain on a machine with no shared failure mode.<\/p>\n\n\n\n S3-compatible destinations cover AWS S3 and any provider that implements the S3 API. The key detail in SPanel’s implementation is a custom endpoint field: it allows backups to go to providers other than AWS – Wasabi for lower per-gigabyte pricing, Cloudflare R2 with no egress fees, DigitalOcean Spaces for ecosystem consistency, MinIO for fully self-hosted object storage, or Backblaze via its S3-compatible interface. You choose the provider that fits your budget and compliance requirements rather than whichever one happens to be the platform’s default.<\/p>\n\n\n\n Backblaze B2 is supported as a first-class destination via its native API via rclone<\/strong>, independently of the S3 path. If you already use B2 for other storage, this lets you route backups there without adding a new provider relationship or working through the S3 compatibility layer.<\/p>\n\n\n\n The table below summarizes the four destinations.<\/p>\n\n\n\n A practical starting point: local backups for fast day-to-day restores, plus at least one offsite destination – remote server or cloud – as your true disaster-recovery copy. That combination satisfies the 3-2-1 rule’s offsite requirement while keeping restore speed manageable for the scenarios you’ll actually encounter.<\/p>\n\n\n\n Hourly file backups leave you with a recovery gap of up to 60 minutes. For most sites, that’s acceptable. For a database under active write traffic, it frequently isn’t.<\/p>\n\n\n\n Consider a WooCommerce store processing orders continuously through the working day. A database migration script runs at 10:14 AM and corrupts the orders table. The most recent hourly backup is from 10:00 AM. Restoring from that backup means losing every transaction placed in those fourteen minutes. For a store with meaningful order volume, that’s a real loss – and for a booking system or subscription platform where each database query represents a customer commitment, the stakes are higher still.<\/p>\n\n\n\n Point-in-time recovery (PITR) closes that gap. Instead of waiting for the next scheduled backup, PITR takes physical snapshots of the MariaDB<\/strong> data directory at short, configurable intervals – every 5, 10, 15, 30, or 60 minutes. Retention is measured in hours: up to 168 hours, or a full week, of granular database history.<\/p>\n\n\n\n The technical approach is non-chained incrementals. Each snapshot is built independently from the day’s full backup rather than from the previous increment. In a chained approach, where each increment depends on the one before, a single corrupted snapshot breaks every subsequent restore point in the chain. With non-chained incrementals, a corrupted five-minute window leaves every other snapshot unaffected. One bad increment costs one increment’s recovery options, nothing further down the line.<\/p>\n\n\n\n When you restore from a PITR point, the system applies the matching snapshot on top of the day\u2019s full backup and hands the result to MariaDB. The database is restored to the selected PITR restore point rather than the last hourly backup.<\/p>\n\n\n\n Restoring to a different database name is also supported. The original database stays intact while the recovered version is created alongside it under a new name, giving you both states to compare before deciding whether to cut over. If you need to download a past database state without restoring it, a direct export to a .sql dump file in your account is also available.<\/p>\n\n\n\n A note on scope:<\/strong> PITR covers MariaDB databases. PostgreSQL<\/strong> databases are protected by the standard file-level backup schedule – each scheduled backup run captures the PostgreSQL data directory – but do not have an equivalent sub-hourly snapshot capability.<\/p>\n\n\n\n Everything covered so far assumes the server still exists when something goes wrong. Disaster recovery is for the scenario where it doesn’t.<\/p>\n\n\n\n Hardware fails, and even cloud virtual machines can be lost without warning or a recoverable state. When the server that hosts your website breaks, you’re not restoring files to a running machine – you’re rebuilding the site itself from whatever backups you have stored offsite.<\/p>\n\n\n\n A full server restore handles this. You provision a new SPanel server, point it at your offsite backups, and run the restore. From there, the process is automated:<\/p>\n\n\n\n Services that would interfere with restoration are stopped first – the database server, mail server, DNS server, and IMAP service. The SPanel metadata directories are restored: account records, DNS zone files, and per-user scheduled tasks. MariaDB is restored next, covering the data directory, credentials, and file ownership. If the original server was running PostgreSQL, the restore detects that from the backup and installs PostgreSQL on the new server before restoring its data directory.<\/p>\n\n\n\n Selected system configuration is restored from backup – specifically the files that need to carry across to the new environment: user accounts, the hostname, web server configuration, SSL certificates, mail server settings, DNS configuration, and firewall rules. Hardware-specific files are left for the new server to manage.<\/p>\n\n\n\n Every hosted account is then restored in sequence: home directories, file permissions, and per-domain log directory structures. Any reference to the old server’s IP address is rewritten to the new server’s IP address across all configuration files. Without this step, database connection strings, absolute URLs in configuration files, and any other hard-coded reference to the old machine would break silently – sites would come back, but parts of them wouldn’t function.<\/p>\n\n\n\n The web server stack is auto-detected from the backup. If the original server ran OpenLiteSpeed, OpenLiteSpeed is installed on the new server, and its configuration is restored. If it ran Nginx, the same. If neither, Apache is the default. You don’t re-configure the web server on the new machine – the restore handles everything for you.<\/p>\n\n\n\n On the empty-server requirement:<\/strong> A full restore will run only on a server with no existing hosted accounts. This is a deliberate safety feature. Overwriting a live server’s accounts, database, and system configuration is irreversible. Requiring an empty destination makes it structurally difficult to accidentally run a disaster-recovery restore against the wrong target.<\/p>\n\n\n\n An important limitation to plan for:<\/strong> Full server restore reads from local backups or remote (SSH\/rsync) backups only. S3 and Backblaze B2 are not currently supported as direct full-restore sources. <\/em>If your only offsite copies are in S3 or B2, the path to a full server restore is to first copy that data to a remote server accessible via rsync, then run the full restore against that remote server. This workaround is straightforward once you know about it – but it’s worth building into your disaster recovery plan before you need it, not during an actual incident.<\/p>\n\n\n\n The scheduled backup system protects you from unexpected problems. Manual backups protect you from expected ones.<\/p>\n\n\n\n Before a major plugin update, a database schema migration, a theme change, or any other modification with a meaningful rollback cost, the right habit is to back up first. If something breaks, you’re restoring from a clean point taken two minutes before the change, not from the last hourly snapshot that captured a version of the site you may not want.<\/p>\n\n\n\n A manual backup lets you choose exactly what to capture: specific folders, specific databases, or the full account. You choose the format – tar or zip – and optionally encrypt the archive before it is stored or transmitted. Optional passphrase-based AES-256-CBC encryption can be applied to the archive before it is uploaded or downloaded. The encrypted file can then be delivered to an FTP server you operate independently of your hosting account, or you can download it to your computer. SPanel<\/a> handles all of this through the same control panel interface used for scheduled backups.<\/p>\n\n\n\n Manual backups sent to your own server sit outside the normal backup rotation. The retention schedule that governs your automatic backups doesn’t apply to them – they persist for as long as you choose to keep them, making them well-suited for permanent pre-change snapshots, compliance records, or any backup you need to guarantee will still be there in six months.<\/p>\n\n\n\n Not every site has the same protection requirements, and not every database in an account is worth backing up. Several configuration options let you tailor the system to your actual workflow rather than applying a single policy uniformly across everything.<\/p>\n\n\n\n Locking restore points<\/strong> prevents the rotation scheduler from deleting a specific backup when newer backups would normally push it out of the retention window. A locked restore point stays in place until you explicitly unlock it. This is useful for compliance snapshots that need to be held beyond the standard retention period, for preserving the pre-migration state of a significant change, or for legal hold scenarios where a specific version of your data needs to be kept indefinitely.<\/p>\n\n\n\n Per-database exclusion<\/strong> removes a specific database from scheduled backup runs without affecting its operation on the server. The database continues to function normally – it simply isn’t included when backups run. For databases that serve as caches, hold temporary session data, or contain nothing that requires protection, exclusion reduces backup time and storage consumption across all configured destinations.<\/p>\n\n\n\n Per-account exclusion<\/strong> works at the account level. An account flagged for exclusion continues to run normally on the server; its data is skipped during backup runs. Appropriate for test accounts, development sandboxes, or accounts where the account holder manages their own backup process independently.<\/p>\n\n\n\n Browsing backup contents before restoring<\/strong> lets you navigate the file tree within a restore point before committing to any restore operation. Before pulling a folder back into the live account, you can confirm the backup contains the version you actually want – the right filename, the right last-modified date, the right directory structure. Verifying first avoids restoring the wrong version and then needing to undo that restore.<\/p>\n\n\n\n Restoring to a different database name<\/strong> keeps the live database intact while recovering an older version alongside it under a new name. Both states coexist on the same database server: the current production version and the past version you’re examining. Once you’ve confirmed the recovered version is correct, you can cut over at your convenience rather than going straight from backup to production with no comparison step.<\/p>\n\n\n\n Backups and security tools protect against different categories of failure and operate on different timelines. They’re complementary – not alternatives to each other.<\/p>\n\n\n\nWhat a Good Backup Strategy Looks Like<\/strong><\/h2>\n\n\n\n
\n
How File and Account Backups Work<\/strong><\/h2>\n\n\n\n
\n
What Makes SPanel\u2019s Backup System Different<\/strong><\/h2>\n\n\n\n
How Retention Schedules Work<\/strong><\/h2>\n\n\n\n
\n
Choosing Where to Store Your Backups<\/strong><\/h2>\n\n\n\n
Local Storage<\/strong><\/h3>\n\n\n\n
Remote Server<\/strong><\/h3>\n\n\n\n
S3-Compatible Object Storage<\/strong><\/h3>\n\n\n\n
Backblaze B2<\/strong><\/h3>\n\n\n\n
Destination<\/strong><\/th> What it protects against<\/strong><\/th> Best for<\/strong><\/th> Restore speed<\/strong><\/th><\/tr><\/thead> Local storage<\/td> Accidental deletion and corruption<\/td> Fast day-to-day file recovery<\/td> Fastest – no network transfer required<\/td><\/tr> Remote server (rsync\/SSH)<\/td> Hardware failure and full server loss<\/td> Offsite protection and disaster recovery<\/td> Fast over a good connection<\/td><\/tr> S3-compatible storage<\/td> Provider outages and vendor lock-in<\/td> Long-term archival and storage flexibility<\/td> Moderate<\/td><\/tr> Backblaze B2<\/td> Provider outages and hardware failure<\/td> Cost-effective cloud backup<\/td> Moderate<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Point-in-Time Recovery: Going Back to a Specific Database Restore Point<\/strong><\/h2>\n\n\n\n
Disaster Recovery: Rebuilding a Server from Scratch<\/strong><\/h2>\n\n\n\n
![\"The](\"https:\/\/www.scalahosting.com\/blog\/wp-content\/uploads\/2026\/08\/The-Complete-Guide-to-Website-Backup-Recovery-and-Disaster-Recovery-Build-1140x513-1.webp\")
<\/figure>\n\n\n\nBefore You Make a Risky Change: Manual Backups<\/strong><\/h2>\n\n\n\n
Controlling and Customizing Your Backup Setup<\/strong><\/h2>\n\n\n\n
Backups and Security: How the Two Work Together<\/strong><\/h2>\n\n\n\n