Backups

[DanLXIX]

I'm wondering what people do about backing up their data. 

I'm currently considering setting up rclone to do regular data backups so app configuation, tracks, routes, Grafana data, etc are backed up to Google Drive regularly, and then I'll occasionally take a full copy of the drive onto an SD Card just for maximum cover - already done this, although where my Pi is sitting it isn't an easy task to restore from it, so it's a last resort sort of thing.

What do you do, and what would you recommend is worth regularly backing up?

[PaddyB]

I had claude code write a little backup app, then use syncthing which is like a local dropbox which copies specified directories ( & music ) across to the laptop on openplotter hotspot

[Trena]

I'm wondering what people do about backing up their data. 

I'm currently considering setting up rclone to do regular data backups so app configuation, tracks, routes, Grafana data, etc are backed up to Google Drive regularly, and then I'll occasionally take a full copy of the drive onto an SD Card just for maximum cover - already done this, although where my Pi is sitting it isn't an easy task to restore from it, so it's a last resort sort of thing.

What do you do, and what would you recommend is worth regularly backing up?

For a Raspberry Pi (especially one running services like Grafana, route tracking, databases, and custom configs), I'd think about backups in layers rather than trying to back up the entire system all the time.

[DanLXIX]

Yeah, I was looking at an incremental process if possible.

I've installed rclone and, with the help of Gemini, I am currently trying to set up an incremental backup process to GDrive. My intention is to have it triggered on a shutdown command so I will stop using the blunt power off shutdown that OP has, so I can run a script to handle it. I've successfully set up a backup to test it, but it wasn't incremental.

It's taking time because I am not an experienced Linix user, and the Pi is in the boat!!

[rdempsey]

I just plug a SSD with a USB adapter in, and use the Pi SD copy program to copy from NVME.
If I need to restore I boot off an SD card and use same copy program to copy from SSD to NVME.
I use the boot priority SD USB NVME 
Done.

[DanLXIX]

That's my safety backup but it's not a process that I want to do every time we sail, only when I make changes bigger than updates. I want to get my daily data backed up just in case something happens as automatically as possible - which does bring up a potential discussion about what should that include.

[SkipperDon]

I’ve taken a slightly different approach with my system (d3kOS), and it might be useful for anyone running OpenPlotter or a Pi‑based navigation setup.

1. Full‑Image Backup (The Foundation)
Instead of trying to back up the entire OS incrementally, I treat the system as immutable.
I keep a full disk image (about 50GB) that contains:

OS

Signal K

OpenCPN

Plugins

Dashboards

Services

Dependencies

UI configuration

If the drive ever dies, I just reflash the image to a new SSD/SD card and the system is instantly back to a known‑good state.
No reinstalling, no reconfiguring, no dependency hunting.

This is the “break glass in case of emergency” restore.

2. User‑Data Backup (Small, Fast, and Automatic)
All the changing data lives in a few predictable folders:

OpenCPN: routes, tracks, charts

Signal K: settings, plugins, certificates

Grafana: dashboards + data

App configs

Logs

Anything user‑generated

These folders are tiny compared to the OS image, so I back them up automatically.

You can do this with:

rclone → Google Drive

Syncthing → laptop or NAS

rsync → local SSD or network share

This gives you daily (or hourly) protection without copying the whole system.

3. Restore Process (Fast and Clean)
If something goes wrong:

Flash the base image

Boot

Drop the backed‑up config folders into a restore directory

Reboot

Everything comes back exactly as it was — routes, dashboards, plugins, settings, charts, the lot.

Why this works well
Trying to back up the entire OS incrementally is slow, fragile, and often unnecessary.
Backing up only the data that changes is fast, reliable, and easy to automate.

This hybrid model gives you:

A guaranteed clean system restore

Automatic protection of your daily data

No need to constantly clone the whole drive

No surprises when restoring after a failure

Anyone running OpenPlotter could adopt the same structure — treat the OS as a fixed image, and back up only the user‑data layer.

[DanLXIX]

That's exactly what I'm working towards as well. Good to know I'm thinking along the same lines, thanks.

[DanLXIX]

Well I got it all working - I had to prompt Gemini a lot to get it all sorted. I have gone for a manually triggered process so the script serves as a "Backup and Shutdown" utility, which means I can choose to shutdown with or without the backup. It synchronises to a Google Drive location using rclone, logs the entire process, and concludes with a graceful system shutdown.

Given it's been a Gemini prompted build, I asked it to give me a summary, in case anyone else is interested 

• Initialisation: The script defines the remote destination and creates a timestamped log file to track the progress of every backup task.
  
• Synchronisation: It employs rclone sync to mirror specific directories to the cloud, ensuring data integrity.
  
• Database Handling: It specifically manages InfluxDB by creating a snapshot and then synchronising that snapshot to the remote storage.
  
• User Feedback: A Zenity progress bar provides a graphical interface during execution. If the backup finishes successfully, it initiates a shutdown; if it fails, it halts the shutdown process to allow you to investigate the logs.
  
• Graceful Closure: Before the final power-off, the script sends `SIGTERM` (-15) signals to key applications (e.g., browsers, Skipper) to ensure they close cleanly and write any remaining data to the disk.
  

Data Backed Up

• /home/pi/.signalk/: All Signal K configurations.
  
• /home/pi/avnav/data/: AvNav routes, tracks, layout, settings, and overlays.
  
• /home/pi/.opencpn/: Specifically `opencpn.conf` and `navobj.xml` files.
  
• /home/pi/.openplotter/: Core OpenPlotter settings.
  
• /home/pi/.Skipper/: SKipper UI and settings.
  
• InfluxDB Snapshots: Captured via the influx CLI.
  

I'm going to use this for a while now and see if anything needs adding or changing - and to see if it is actually working as expected!

[SkipperDon]

you should post the solution in " How I did it" detailing the script etc. Congratulations! looks good