Backup and restore ArangoDB data

You can easily back-up and restore the ArangoDB database from Windows. All you need is WinSCP, Putty, and some diskspace. I’m running the batch script below every time I login to my workstation automatically to backup the configuration database:

plink -batch -pw xxx -t root@ "systemctl stop arangodb3"
plink -batch -pw xxx -t root@ "cd /data/backup && zip -r /data/arangodb/data"
plink -batch -pw xxx -t root@ "systemctl start arangodb3"
pscp -pw xxx -v -r root@  G:\IoT\ArangoDB\
plink -batch -pw xxx -t root@ "rm /data/backup/"

You can restore the database by installing ArangoDB on another system and copying the data back into the correct directory. Make sure you stop the ArangoDB service before you restore the data.

When the ArangoDB version on the target system is newer then the ArangoDB version on the source system you need to upgrade the database first. Stop the ArangoDB service and start it in the console with the – parameter:

systemctl stop arangodb
/usr/sbin/arangod --uid arangodb --gid arangodb --pid-file /var/run/arangodb3/ --temp.path /var/tmp/arangodb3 --log.foreground-tty true

Installing the UniFi Network Application on Raspberry Pi

Unfortunately MongoDB does not have an ARM64 bit package for Raspberry Pi yet, so I’m installing this on a Raspberry Pi with a 32-bit (Debian-based) Raspberry Pi OS:

sudo apt update && sudo apt full-upgrade -y && sudo apt autoremove -y && sudo apt-get autoclean -y
sudo apt install openjdk-8-jre-headless jsvc libcommons-daemon-java -y
sudo apt install haveged -y
sudo apt install mongodb-server mongodb-clients -y

echo 'deb stable ubiquiti' | sudo tee /etc/apt/sources.list.d/100-ubnt-unifi.list
sudo wget -O /etc/apt/trusted.gpg.d/unifi-repo.gpg
sudo apt update && sudo apt install unifi -y

Go to your UniFi Controller via the IP address and port, for example:

Installing .NET 6 on a Raspberry PI (Debian)

Create a folder, for example /app/dotnet6, and assign ownership to the right user:

sudo mkdir /app/dotnet6
sudo chown -R pi /app/

Download the .NET 6 SDK at Microsoft:


Extract the tar.gz file in the /app/dotnet6 directory:

sudo tar zxf dotnet-sdk-6.0.100-linux-arm64.tar.gz -C /app/dotnet6

Test the .NET6 installation by browsing to the installation directory and execute the dotnet –info command:

cd /app/dotnet6
./dotnet --info
.NET SDK (reflecting any global.json):
 Version:   5.0.101
 Commit:    d05174dc5a

Runtime Environment:
 OS Name:     debian
 OS Version:  10
 OS Platform: Linux
 RID:         debian.10-arm64
 Base Path:   /app/dotnet/sdk/5.0.101/

Host (useful for support):
  Version: 5.0.1
  Commit:  b02e13abab

.NET SDKs installed:
  5.0.101 [/app/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.1 [/app/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.1 [/app/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:

InfluxDB update from 1.8.6-1 to 1.8.7-1

Upgrading InfluxDB failed. For some reason the update caused permission issues with the start-up script:


When I gave this file permission to execute the InfluxDB service started again:

chmod +x /usr/lib/influxdb/scripts/

Then, the next problem appeared: systemctl didn’t recognise that the service was actually running: it was stuck in the state “activating”. Then I found an article on serverfault that described my problem.

I’m running InfluxDB on Debian so couldn’t apply the suggestion solution, but needed to interpret this a bit. I edited the file:


I changed the type to simple, as indicated in this code sample:

Description=InfluxDB is an open-source, distributed, time series database



Check the disk space consumption of a Linux directory

Today, one of my virtual systems ran out of disk space. To find the root cause I needed to find the directory that was filling up. Using the right parameters, the du command returns a list of directories and their disk space consumption.

du -hc --max-depth=0 /var

For example:

root@DB152:/# du -hc --max-depth 1 /var
704K    /var/tmp
4.0K    /var/mail
23M     /var/log
1.1M    /var/backups
4.0K    /var/local
3.2G    /var/lib
20K     /var/spool
734M    /var/cache
4.0K    /var/opt
3.9G    /var
3.9G    total

Removing files of a certain type recursively:

find . -name "*json.log" -type f -delete

Clearing (system) log files:

truncate /var/log/* --size 0