Operating Systems, such as Linux, tend to write data within files on hard disk drivces (HDD) during runtime. This also occurs within virtualized and/or containerized environments. Based on workloads, logs and application data generate hard disk i/o which slows down application performance and processes the lifespan of physical hardware such as HDD, SSD or hybrid devices.
In the days of Raspberry Pis, which utilize SD-Cards, persistence storage must be spared as much as possible due to its limited lifespan. Therefore disk i/o can be shifted to in-memory using Linux tmpfs capabilities. Even though this favors disk i/o, this comes on the price for persistence. Data is lost during a reboot or service interrupt. Proper backup and persistence concepts is key.
The given example is for an OpenHAB workload installation. File locations differ based on use-case and workload.
Configure workload i/o to in-memory
Shift all major disk i/o to a temporary (in-memory) filesystem:
sudo vim /etc/fstab tmpfs /var/lib/openhab2/persistence/rrd4j tmpfs nosuid,size=250M 0 0 tmpfs /var/lib/openhab2/persistence/mapdb tmpfs nosuid,size=250M 0 0 tmpfs /var/log/openhab2 tmpfs nosuid,size=250M 0 0
Configure backup/recovery location
Create backup directories to store backups for recovery of your in-memory spaces. You can take any file location, /opt contains optional software, therefore I utilize this location:
mkdir /opt/openhab2 mkdir /opt/openhab2/persistence mkdir /opt/openhab2/persistence/rrd4j mkdir /opt/openhab2/persistence/mapdb
Schedule automatic local backups
Once backup locations are created, a regular shift from in-memory to the backup location must take place. As this is a time-based local backup, keep in mind, that any data between intervals is lost during a system outage. There are additional possibilities to store live-data such as logs in central repositories (e.g. Elastic Stack) and keep this location as plan backup.
# Delete current log (no backup) 0 3 * * * echo -n > /var/log/openhab2/openhab.log 0 3 * * * echo -n > /var/log/openhab2/events.log 0 3 * * * echo -n > /var/log/openhab2/audit.log # Backup application data 0 */4 * * * cp -r /var/lib/openhab2/persistence/rrd4j/* /opt/openhab2/persistence/rrd4j/ 0 */4 * * * cp -r /var/lib/openhab2/persistence/mapdb/* /opt/openhab2/persistence/mapdb/
Auto-Recovery after reboot
To shift application data back into memory after system restarts, it is important to access the backup location and shift data to the in-memory location. Data between shifts cannot be recovered, as they were not backed-up. Interval and other persistence mechanisms are key. Keep in mind to add the block before exit 0, otherwise it will be skipped:
sudo vim /etc/rc.local [...] # Recover data after reboot cp /opt/openhab2/persistence/mapdb/* /var/lib/openhab2/persistence/mapdb/ cp /opt/openhab2/persistence/rrd4j/* /var/lib/openhab2/persistence/rrd4j/ # Recover permissions (in-memory location) chown openhabian:openhabian -R /var/lib/openhab2/persistence chmod 777 -R /var/lib/openhab2/persistence [...] exit 0
Test your configuration
Test your configuration once completed for proper function. You don’t want to see your data gone after a system downtime.
