An important thing to consider for any Blocks installation is making sure there's a backup routine in place. The exact method and frequency of backups isn't the main point here – merely that it gets done at all. If a Blocks system is installed, configured and then left running with little or no change, taking a backup once the installation is complete may be sufficient. On the other hand, if the system is updated frequently, possibly by different users, you may want to have backups made daily, or even hourly.

Fortunately, backing up your Blocks system is relatively straightforward. All data used by Blocks lives in the "Blocks root" folder. On our linux-based server, this folder is found at /home/pixi-server/PIXILAB-Blocks-root.

A basic but fully functional backup strategy is to manually drag this "Blocks root" folder over to a USB stick, which is then removed and stored safely. To keep a few more copies, just use a number of USB sticks you cycle through, putting each one in a bag with the latest date noted on the bag. Since the USB stick is removed from the server computer once the backup is done, this also protects your backups against theft and other more disastrous events.

If you have an IT department as part of your organization, you best option may be to ask them to include your Blocks server in their existing backup routine. Since all that it takes is to copy the "Blocks root" folder to a safe place on a regular basis, it's very straightforward to implement as part of a company-wide backup strategy.

In many cases, your Blocks server may be installed at a location where there is no one around that can manage backups, and you may be the person they call when they need help. In this case, it can make sense for you to offer remote backups as part of an ongoing support and maintenance agreement. In such cases, you likely have a remote connection to the Blocks server on site (possibly based on [url=/docs/blocks/anydesk]Anydesk[/url], or a VPN). Since you have remote access to their Blocks server, you can run backups on their behalf.

Remote backups can be made in a number of ways, such as accessing their Blocks root folder over SMB file sharing and just copying the folder, or using rsync remotely (over a VPN or Anydesk TCP tunnel). Such a solution can be based on the snapshot.sh script discussed above, but changing the file source to include the user name and remote server IP address. Or use dedicated backup software that includes support for backing up remote computers over the network.

Another, somewhat related, method is the script-based "snapshot" feature already built into our Linux server image. While not really a viable backup-strategy, this feature simply takes a snapshot of the current state of your Blocks root folder. Those snapshots, marked with date and time, are stored in the "Blocks-root-snapshots" folder. To take such a snapshot, log in as the pixi-server user, and run this command in a terminal window from your home directory (i.e., /home/pixi-server/):

./snapshot.sh

There's a corresponding script that will restore your Blocks root to the most recent snapshot taken:

./restore-current-snapshot.sh

CAUTION: Executing the restore-current-snapshot.sh script will overwrite your current Blocks root with the snapshot. Shut down your Blocks server before executing the restore script.

Older snapshots can be restored manually by replacing your current PIXILAB-Blocks-root with the corresponding one found inside the desired snapshot folder.

This local snapshot method is useful particularly in the production phase, where it allows you to make frequent snapshots in an efficient way, allowing you to revert to an earlier state should you make some mistake, such as removing the wrong block (along with all its media files), or similar. These snapshots are store in a clever way, making subsequent snapshots very fast (and also disk space efficient), even though each snapshot contains a complete set of files (for the technically inclined, this uses a file system feature called "hard links").

A disadvantage of this method is that the snapshot files are stored on the Blocks server. This requires some additional disk space, and if the computer is stolen or the disk dies, your snapshot is gone too.

Any of the methods mentioned above can help you restore lost data from the backup or snapshot, should needs arise. However, they do not protect the server itself. If your presentation environment is heavily dependent on your Blocks server and its data, you need to consider both the data and the hardware itself – the physical box that the Blocks software runs on. How much downtime do you consider acceptable if the computer dies? It could be the power supply, SSD storage or other components.

As long as you have up-to-date backups of the data, new server hardware would can be procured and the server can be re-built in terms of software installed, network configuration, etc. Your backup can then be restored to this new server, bringing you back on track. If you're not OK with taking the time to do this if disaster strikes, it can make sense to keep an extra server around, ready to be deployed when needed. Blocks actively supports such a spare server with its Mirroring Service, automatically keeping all data on the spare server in sync with your active server. This arrangement allows you to switch over to the spare in a matter of minutes rather than days or weeks.

NOTE A Mirror server will bring you back on track quickly if hardware failure strikes. However, this is not a backup strategy, since the Mirror server won't keep copies of old data. Any data deleted from the active server will also be automatically deleted from the mirror copy.