Backup and Disaster Recovery with StorPool
Ensure business continuity
for your customers

Backup and Disaster Recovery

Backup and Disaster Recovery are of major importance for the quality of the IT services a company can offer. The reliable and up-to-date backup guarantees you will be prepared to restore data in case of loss. On the other hand, a Disaster Recovery solution ensures the business continuity for your customers. These two options are both provided by StorPool Storage in our efforts to help you in providing a top-notch solution and getting a strong competitive advantage.

Along with its built-in redundancy, guaranteed through synchronous replication algorithm, StorPool offers a number of backup mechanisms.
There are several different ways in which backup and Disaster Recovery (DR) functionality can be performed in a StorPool SDS setup. These solutions require simple configuration or some scripting in order to be deployed and fully functional.

Periodic snapshots in the primary cluster

StorPool users can create periodic snapshots in their primary storage system. Peeking inside snapshots to retrieve individual files can be achieved easily using one of the following methods:

  • guestfish
  • attach as an additional disk to a VM
  • attach in host

Note to hosting users: this is not integrated with cPanel, so it is best suited for restoring whole shared hosting VMs.

cPanel backups for shared hosting

This covers: Cpanel integrated backups, jetbackup or similar solutions. In this case, companies can use a second StorPool cluster with large HDDs and expose iSCSI to the VM (either directly or with the initiator in qemu/KVM).

Volumes from the second StorPool cluster will appear as /backup directories in the cPanel VMs. The benefit of using StorPool, in this case, is better performance on the same hardware (e.g. 4 TB HDDs) and better data management capabilities (snapshots, and potentially run from backup).

Off-site backups and DR, using StorPool snapshots

StorPool can also send snapshots, which customers have created in one cluster/site/datacenter to a StorPool cluster in another site/datacenter. In addition to the scenarios in point 1, this also protects against whole site (or whole cluster) failure. It gives you the ability to run your workloads/service from the backup repository in a separate site.

Generally speaking, StorPool snapshots stored with 3 copies on 4 TB HDDs should have enough performance to run the service with decreased performance. To run the service in the DR site, customers obviously need free CPU and RAM in the same datacenter as the backup cluster.

Best practice for disaster recovery cases is to have 2 identical set-ups in 2 different data centers, so each of them can run the workloads of the customer without any performance degradation.

Backup target servers

In case you are using a backup solution with a client/server architecture, e.g. Veeam, R1 Soft, Bacula, Acronis, etc. Customers can encapsulate the backup target (aka backup repository) in a VM on top of a StorPool cluster. This means you’re virtualizing the target side of the backup service.

A virtualized backup target has several benefits over a physical server backup target:

  • The main benefits are high availability and better resource utilization.
  • The specialized backup protocol will likely perform better than iSCSI/rsync at larger distances (e.g. between data centers).
  • In case of cPanel: this gives you the ability to separate backup agent and backup target by a larger distance, e.g. put them in different datacenters.