How does Disaster Recovery works

Backups are automatically-created disk images of Pods (servers). JungleWP automatically enables system-level backups at weekly intervals, which provides a way to revert to an older state or create new Pod.

Regional Availability

Backups are available for all Pods across all regions.

Features

Backups are taken once per week, and each backup is retained for four weeks. We store backups in the same datacenter as the corresponding Pod, and additionally store a second copy offsite.

How Do JungleWP Pod Backups Work?

JungleWP uses a snapshot-based backup system that creates a point-in-time image based on the current state of aPod. This process happens automatically within a predetermined scheduling window, and is completed in the background while the Pod is running. This provides system-level backups of your server without powering down.

The following process occurs on your Pod when a backup occurs:

1. A snapshot of the live system is taken, creating a crash-consistent, point-in-time image.
2. The snapshot is backed up off-disk.
3. The snapshot is deleted once the backup is complete.

A crash-consistent backup allows the system to capture all of the data on disk exactly as it was at a single point in time. This means that the data is backed up in a consistent state.

This is called a crash-consistent backup because it saves every piece of data that was committed to the disk at the moment that the snapshot occurs. The data saved is consistent with the data that would be available if the system crashed at that exact point and had to recover on boot.

Backup Schedule

Once you’ve enabled backups, they are scheduled to occur weekly during a specific time window which is automatically assigned by JungleWP. To view the time window when your backups will start, navigate to your Pod in the JungleWP Control Panel, and click the "Pod Backups" link.

In the Pod Backups view, select your Pod from the list to display the weekly backups:

Backups are currently enabled. They are scheduled to start weekly.

Limits

• Backups are not encrypted at rest, but they are not externally accessible.
• JungleWP’s automated backups are not manual backups.
• JungleWP backups are optimized for systems with low write activity. For systems with active database writes and other high I/O workloads, a WordPress Real-Time backup like the one we provide in our Premium Care Plans may be more appropriate.

The snapshots that are taken to create the point-in-time data set use a copy-on-write mechanism. Copy-on-write allows for instant snapshots which make them a good choice for data consistency. There is almost no overhead for the actual creation of the snapshot that will be backed up.

However, copy-on-write implementations do take a performance hit on new writes that occur  after the snapshot is taken until the backup process is complete. This happens because, for every new write, a system using copy-on-write must read the original data, write it to a new location, and then write the new changes to the original data location. This can significantly impact performance on busy, I/O bound workloads. The performance impact disappears when the snapshot is automatically deleted after the backup operation.

Databases are especially affected by this. Most database operations are heavily reliant on disk I/O, which can cause the application or the backup process to bog down and sometimes fail. In addition to the performance impact, operations that reside in memory or cache that has not been flushed to disk will be lost. Crash-consistent backups always save what is on the disk, but never what is in memory or cache.