By David Fox
P5 Backup2Go is Archiware’s workstation backup product, it reads from the workstations disks and writes to a central disk-based repository. Here, many time-based snapshots of the workstations data are retained and available to restore from. In this Spotlight article, we explore two modern file systems that support native snapshots and how these can be used to more effectively back up workstations and generally enhance Backup2Go’s reliability and performance.
How P5 works with “traditional” file systems
If your workstation is being backed up with Backup2Go, and you’re looking to restore a file from the backup to your workstation, you would expect to be able to restore one of several versions of the file available to you. You may wish to recover the most recent version, but perhaps you prefer one from a week ago. In order for Backup2Go to back up a workstation, and retain many different versions of files over time in this way, it has to implement a way to store this data from different points in time, and retain separation between these different ‘snapshots’.
In ‘traditional’ file systems such as NTFS (Windows), HFS+ (MacOS), EXT and XFS (Linux) and others, P5 is required to maintain special directories to hold the snapshots and perform a complex system of links and duplication in order to implement storage of the backup snapshots on a file system not inherently designed to support snapshots of data. This is how Backup2Go works with these traditional file systems.
Btrfs and ZFS – better file systems for storing backups
Btrfs and ZFS do feature native support for snapshots, and such support brings many advantages to software like Backup2Go: The snapshot storage becomes vastly simpler, quicker and more efficient. By having native support for creating point-in-time snapshots of data, Backup2Go writing to one of these file systems is able to create a snapshot almost instantly. Therefore, it’s worth considering switching to one of these file systems to build a better workstation backup solution for your users.
Btrfs (B-tree file system) is supported on various different Linux distributions and is the default for the root partition on SUSE Linux. It is also the default file system on Synology NAS devices, making them an ideal Backup2Go server platform.
ZFS was originally developed by Sun (now Oracle) for their own Solaris operating system. It’s also available to install on Linux, but isn’t directly supported by distributions in the same way that Btrfs is. ZFS can also be installed on FreeBSD.
Backup2Go’s backups repositories will comprise vast numbers of files/folders, and each run of a workstation backup will change a small subset of these files. Using traditional file systems, each point-in-time workstation backup requires maintaining a separate folder, while creating links between previous and future backups to avoid storing the exact same file multiple times, and wasting disk space.
Achieving this complex dance often places significant load on the machine hosting Backup2go and the storage it is writing to, many disk operations are generated by each new backup and the whole system can become slow, with increased possibility of backups being missed – especially where modest hardware is employed, such as an Apple Mac mini.
Using Btrfs/ZFS to manage the target storage for Backup2Go will result in a more reliable solution, also requiring less maintenance.
In order to begin using Backup2Go with Btrfs or ZFS, the following broad steps should be considered:
- Select an OS that supports the filesystem you wish to use, e.g. Linux
- Select hardware to run it on
- Attach storage for the Backup repository, using RAID for redundancy
- Install and configure P5 Backup2Go
If you’re currently running Backup2Go on hardware that doesn’t support Btrfs or ZFS, it will be necessary to switch to a platform supported by the file system.
One possible option, as mentioned above, is to move your Backup2Go installation to a Synology NAS device, which runs Linux, has native Btrfs support, and includes within the hardware the possibility to connect multiple hard drives and configure them within a RAID array. Configuration of disks into an array which has redundancy, and can therefore survive a hard drive failure without data-loss, is critical for a reliable Backup2Go solution.
While you may have older workstation backup data on your previous installation, it will be necessary to begin workstation backup over again after creating the new installation writing to the new filesystem. If you need to use the same disk array, it will be necessary to reformat as Btrfs/ZFS, requiring loss of all previously written workstation backup data.
The benefits available for workstation backup when using Btrfs or ZFS are considerable, and while there is some work necessary to migrate an existing installation, we feel that the effort is easily rewarded. When deploying a new installation of Backup2Go, it is best to only consider using a snapshot-capable filesystem.
For smaller installations backing up less than 20 – 25 workstations, a traditional file system may well be sufficient, since the complexity and workload is limited. However, if you are planning to back up a larger number of workstations or additional requirements have to be met, there is no way around using Btrfs or ZFS.
We are aware that 20 – 25 is a vague definition of an upper limit. But it’s impossible even for Archiware as the manufacturer to give a definitive figure here, since numerous factors other than the sheer number play into it: The amount of data to be backed up plays a critical role, as does the frequency with which it is being backed up daily, and of course the performance parameters of the hardware: CPU, memory, read/write performance of the RAID systems and, naturally, network performance.
All of these factors also require consideration when answering the question how many workstations can be backed up using a single P5 server. Experience from past years shows that – even assuming a good general setup on a snapshot-capable file system – the limit is around the 100 workstation mark.