I've previously written about my backups, the server they were running from, and the NAS drive problems i have had. I've also had issues getting the backups up to the cloud for a while, but I figured my problems were solved when the Raspberry Pi Foundation released the 8GB Raspberry Pi.
My initial cloud backup provider didn't provide an application for ARM processors, which I stupidly didn't factor in to the purchase, so I found a one which has support for Linux, specifically mentioning Ubuntu. Great, I thought, I can run Ubuntu on my Pi and go from there.
Creating the Boot Drive
The Raspberry Pi foundation provides a tool for creating bootable SD cards, which will do the hard work for you. However, the package wouldn't install first time on Ubuntu 20.04 LTS when running
sudo dpkg -i imager_amd64.deb
You need to install a load of QML modules it needs. Simply run the following in your terminal
sudo apt install -y qml-module-qtquick-controls2 qml-module-qt-labs-settings qml-module-qtquick-layouts qml-module-qtquick-templates2 qml-module-qtquick-window2 qml-module-qtgraphicaleffects
Then you can run the dpkg command and all should be fine. The Raspberry Pi imager tool is then available to run from the applications menu. I tried using the snap package, but that wouldn't run for me, hence the long winded approach.
With the imager running, tell it to create the Ubuntu 20.04 LTS server, select the card, and hit Write. Simple, really. It will create the image and verify it on the card. Once complete, just pop the MicroSD card into the Raspberry Pi, and go.
Mapping the Drive
My NAS drive is a Buffalo LinkStation, with Raided drives to mirror the contents, and provide a nice level of security if something bad happens. It means I have a wonderful 4TB storage on it, and it's available on the network. To back it up to the cloud, it needs to be mapped as a drive (and my previous cloud backup provider didn't allow mapped drives on Windows, so I needed a Linux solution).
Fortunately, Linux is designed for these types of things, and after installing cifs-utils (`apt install -y cifs-utils`) it was a simple case of mapping the samba share:
mount //servername/share /folder/to/map/to -t cifs -o username=myuser,password=mypass,vers=samba-version
In the case of my NAS,
vers needs to be 2.0 to work, any other output gives the bash output of:
mount error(2): No such file or directory Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)
To get the drive to mount when the machine boots up, the entry needs to be made in
/etc/fstab. The information is pretty much the same as a manual mount, above, but misses out the
mount command, and the flags ahead of the options. My fstab entry for the drive above looks like:
//servername/share /folder/to/map/to cifs username=myuser,password=mypass,vers=samba-version 0 0
Save the changes, then run
mount -a. The drive should mount to the relevant location. To fully test, reboot the machine and log in. It should be mounted ready.
My new chosen backup provider is IDrive, as I saw a link from TechRadar offering a years backups (up to 5TB) for absolute peanuts. They also happened to have Linux backup support via Perl scripts. It was worth a try, I figured.
Unfortunately, it wasn't always that easy. Trying to run the
account_setting.pl script ran into issues with "Unable to verify EVS Binary". Not a lot of help out there for that, but I eventually hacked my way through the files to find areas to add logging. I eventually had to download the relevant ARM 64-bit binary from https://www.idrivedownloads.com/downloads/linux/download-options/IDrive_synology_aarch64bit.zip. and manually extract that to the
scripts/iDrivelib/dependencies folder, ensuring the
idevsutil was in the
Next was the error "Unable to download static Perl binary". Further hacking and digging showed that the scripts only try to download an x86_64 binary of Perl. IDrive have seen this before, and have an FAQ for it. You need to download a zip file based on the machine architecture, and pass it in as a command line argument for it to work. Using the ARM architecture one caused an issue, as the hardware platform registered as 64-bit, so it wanted the IDrive_Linux_64.zip file passing in. The issue here was it didn't like the zip archive which was downloaded.
This was easier to fix than you would expect. Simply use the archive manager to extract the zip archive, rename the zip archive, and zip the extracted folder. This will zip the files in the manner which is needed by your system to access it correctly, and then the
account_setting.pl script can extract the archive correctly. Everything then ran as expected.
Configuring the Backup Set
For IDrive to work, it needs to know what to back up. The script for doing this is within the
scripts folder of the IDrive installation. Just run
./edit_supported_files.pl and follow the instructions. This will open the configuration text file in vi, which can be daunting to those who don't know how to use it. If this worries you, and you're more used to nano or something else, edit the file BackupsetFile.txt in the location
idriveIt/user_profile/MACHINE_USER/IDRIVE_USER/Backup/DefaultBackups. For this path, the following are important:
idriveItfolder is in the same folder as the
scriptsfolder where all of the IDrive work takes place
MACHINE_USERis the user for logging into the machine
IDRIVE_USERis the email address for logging into IDrive with
I set this up to back up the folder
/home/ubuntu/Alexandria (I have a slight Greek theme on my machines, generally. My old file server was called Hercules. My NAS folder is like the library at Alexandria.)
Running the backups
Once everything is configured, simply run
./Backup_Script.pl. It will read the locations from the BackupsetFile.txt file, and upload them to IDrive. It makes sense to do this in a specific window, as it outputs the progress and stats for the backups. In my case, I had 1.45TB files to back up, which was going to take a long time.
./scheduler.pl to configure the cron job. Se this to start later, and then modify the entry to specify a start and end time.
Because I set my cron job to run at a point earlier in the day, and wanted it to start immediately, I then logged in to the machine and re-ran the
./Backup_Script.pl file to get things going. I kept the occasional eye on it by connecting to the Raspberry Pi via SSH, navigating to the IDrive scripts folder, and running
./Status_Retrieval_Script.pl. This will guide you through a menu to to find running options, and then output what is happening on to screen. Should you wish to exit this, use the normal Ctrl+C to exit. This only affects the
./Status_Retrieval_Script.pl script, not the Backup_Script running in the background.
Getting cloud backups running on a Raspberry Pi might not be easy, but it is certainly doable. And unless you need more than 5TB storage, it's not going to cost too much either.