Geek On The Hill

As I’ve said before, you can never have too many good backups stashed in too many different places; and one of the places I stash backups of my cPanel servers is Backblaze B2.

I use B2 as a tertiary, or “Doomsday” backup destination. The backups stored in /backup on the server are the primaries, and a single copy of the most recent backup copied over to Amazon S3 using cPanel’s built-in backup configurator is the secondary. But I also send a copy of the backups to Backblaze as tertiary backups with 10-day retention, meaning that the 10 most recent backups are retained.

The reason I do this is in case the most recent backup generated by cPanel (and copied to Amazon) is corrupt, infected with malware, or otherwise unusable. In that event, I can select from the 10 most recent backups stored on Backblaze. The reasoning behind this is that Backblaze is much less expensive than S3 — but only if you never actually need the backups. Uploads and storage are dirt-cheap on B2, but download costs can be pretty hefty. That makes it a great place to stash backups that you don’t expect to ever need.

The other advantage to using Backblaze is that you can save multiple versions of your backup files without taking up so much space on your server’s hard drive. Just set the retention in cPanel’s backup configuration to one, but use B2’s Lifecycle Rules to set retention to something longer, like five or ten. That way you’ll only be saving the most recent backup on the server. The rest will remain on Backblaze until they’re pushed out by newer backups, up to the limit of retention days you’ve defined.

To back up to S3, you need a Backblaze B2 account, of course. Once you’ve opened your account, copy your Account ID and Application Key to a safe place like a text file inside an encrypted folder. You can never recover your Application Key, so back it up and don’t lose it. If you have to create a new key, any scripts or jobs that you created using the previous key will stop working.

Next, create a bucket in B2. Give it a unique name that you’ll recognize, like “my-server-backups” or something along those lines. I suggest that you create a separate bucket for each server. There is no cost for creating additional buckets, and they help keep things organized. Then use Lifecycle Rules to create a retention period (I usually use 10 days). Finally, upload a small text file into the bucket. Name it “testfile.txt” or something like that.

You’ll also need to install a program called rclone on your server. You’ll need to use SSH for this. If you don’t have an SSH client and are using a windows local machine, download an SSH client. I personally like puTTY. If you’re unfamiliar with working in SSH, I suggest you read this tutorial before proceeding.

Log in as root (or become root once you’ve logged in), and install rclone following the instructions for your server’s operating system. Note that rclone is a terminal (“command-line”) program that will not integrate into cPanel’s GUI. You’ll have to install it, configure it, and run it using SSH.

Once rclone is installed, type

$ rclone config

The first thing you have to do is create a new remote. When you see this prompt:

No remotes found - make a new one
n) New remote
q) Quit config
n/q>

Type n and hit Enter to create a new remote. You’ll then be presented with this prompt:

name>

Type in a name for this particular backup job. You can call it whatever you want. I usually just call it “backblaze” if that’s the destination.

The next prompt you’ll see is:

Type of storage to configure.
Choose a number from below, or type in your own value
 1 / Amazon Drive
   \ "amazon cloud drive"
 2 / Amazon S3 (also Dreamhost, Ceph, Minio)
   \ "s3"
 3 / Backblaze B2
   \ "b2"
 4 / Dropbox
   \ "dropbox"
 5 / Encrypt/Decrypt a remote
   \ "crypt"
 6 / Google Cloud Storage (this is not Google Drive)
   \ "google cloud storage"
 7 / Google Drive
   \ "drive"
 8 / Hubic
   \ "hubic"
 9 / Local Disk
   \ "local"
10 / Microsoft OneDrive
   \ "onedrive"
11 / Openstack Swift (Rackspace Cloud Files, Memset Memstore, OVH)
   \ "swift"
12 / SSH/SFTP Connection
   \ "sftp"
13 / Yandex Disk
   \ "yandex"
Storage>

At the time of this writing, Backblaze is option 3, so type 3 and hit Enter.

You’ll next be prompted for your Account ID:

Account ID
account>

Type or paste your Account ID after the > and hit Enter. The next prompt will ask you for your application key:

Application Key
key>

Type or paste your application key and hit Enter.

The next prompt will be:

Endpoint for the service - leave blank normally.
endpoint>

You can leave that blank in most cases.

At this point the script will present you with the configuration and ask you to accept it:

Remote config
--------------------
[remote]
account = [ your account ID ]
key = [ your application key ]
endpoint =
--------------------
y) Yes this is OK
e) Edit this remote
d) Delete this remote
y/e/d> y

If it all looks good, then type y to accept it. If not, type e to edit it or d to delete it, and hit Enter.

Congratulations, your rclone configuration is done.

Now you want to make sure that you can connect to your bucket. You can find an exhaustive list of rclone commands here and I suggest you read up on them. But for the purposes of this tutorial, I’m only going to mention a few. The first will be a simple test to see if you can connect to your bucket. Assuming that your bucket is named “my-server-backups,” and the name you gave to the rclone job is “backblaze,” type this into the shell:

rclone ls backblaze:my-server-backups

You should be able to see the text file that you uploaded to the bucket when you created it.

At this point, you may want to run a manual backup to see how long it takes to copy your cPanel backups to Backblaze B2. I suggest you do this during a time when server traffic is light. Assuming that your cPanel local backups are stored in the default /backup directory on your server, the command to copy them over to B2 would be:

rclone copy /backup backblaze:my-server-backups --transfers 16

That last part, --transfers 16 , is an optional flag specifying the number of transfers to run in parallel. If you leave it out, rclone will use four by default, which will make for quite a slow backup. On my servers, I find that 16 works well. It moves the files pretty quickly without slowing the machine to a crawl. You may need to use fewer, or you may be able to use more.

Finally, if you want to run rclone as a cron job, find a good time well after the local backup and any other remote destination transfers are completed, and when nothing else resource intensive is scheduled to run, and add the new job as the last line in crontab by executing crontab -e from the shell. That will open crontab for editing using the default editor.

The syntax to run the above backup at 4:00 a.m. every day would be:

0 4 * * * /usr/bin/rclone copy /backup backblaze:my-server-backups --transfers 16

You can learn more about using cron here.

Once you’ve set up your cron job, check every so often to make sure that the files are being properly transferred and that the cron job scheduling isn’t conflicting with anything else or running into your high-traffic hours. You can also use cPanel hooks to append the process to the cPanel backup job. I personally prefer using cron so I can avoid interfering with other scheduled maintenance jobs such as updates and the like.

If you ever need to use the backups to restore an account to a server using cPanel’s Restore from Backup function, you would copy the account’s backup file to the /home directory of the new server (which is where cPanel will look for it) by installing rclone on the new server, configuring the remote identically to the configuration on the old server (that is, using the same Account ID, Application Key, and Bucket name), and executing

rclone copy backblaze:my-server-backups/[path information]/account_name.tar.gz /home

Assuming again that the remote name is “backblaze” and the bucket name is “my-server-backups”.

The [path information] would be whatever information precedes the name of the backup file itself. For example, it might be something like:

my-server-backups/2018-01-14/accounts/account_name.tar.gz

in which case, the command to copy it from the remote to /home would be

rclone copy backblaze:my-server-backups/2018-01-11/accounts/account_name.tar.gz /home

In summary, Backblaze is a very inexpensive place to stash backups that you don’t think you’ll ever need. I wouldn’t use it as the primary or sole backup destination because of the relatively high cost of downloads, especially if your clients are in the habit of hosing their accounts and needing restores. It could start getting pricey. But for a bit of extra security in the form of multiple versions of an account backup in case of a doomsday event, Backblaze B2 is hard to beat.