Backup and Disaster Recovery are of major importance for the quality of the IT services a company can offer. A 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 scripting in order to be deployed and fully functional.
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:
Note to hosting users: this is not integrated with cPanel, so it is best suited for restoring whole shared hosting VMs.
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).
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.
Users of a backup solution with a client/server architecture, such as Veeam, R1 Soft, Bacula, or Acronis, 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: