# Homey SHS - Backup strategy for running docker

**URL:** <https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407>\
**Category:** Homey Self-Hosted Server\
**Created:** [January 2, 2026, 11:08pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407 "2026-01-02T23:08:47Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![bwa](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/bwa/32/17852_2.png) [@bwa](https://community.homey.app/u/bwa)\
**Post date:** [January 2, 2026, 11:08pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/1 "2026-01-02T23:08:47Z")

</div>

So my SHS is running in docker and I have mounted a volume outside.

I’m using continus backup to my Jottacloud for the mounted volume, but is that safe ? There is a sqllite directory there. Do I need to stop container and schedule backup instead ?

 ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/8/5/851eafda27205dbb21e231bc257845a631b032b7.png)

---

<div class="post-metadata">

**Author:** ![Sharkys](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/sharkys/32/54029_2.png) [@Sharkys](https://community.homey.app/u/Sharkys)\
**Post date:** [January 3, 2026, 7:49am UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/2 "2026-01-03T07:49:06Z")

</div>

Well, at minimum, you are backing up live system so eg. for SQLITE, I would suggest doing some research on continues backup to my Jottacloud vs data integrity of SQLite DB being constantly updated. My best guess would be that on a highly used system that could be a problem, even Homey is using journaling, so could be OKay….

---

<div class="post-metadata">

**Author:** ![bwa](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/bwa/32/17852_2.png) [@bwa](https://community.homey.app/u/bwa)\
**Post date:** [January 3, 2026, 8:14am UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/3 "2026-01-03T08:14:34Z")

</div>

Maybe a feature request for Homey to create a backup function flow card, that creates a consistent backup in some /backup folder. I’ll create a ticker for that. It should be easy for Homey to implement

---

<div class="post-metadata">

**Author:** ![Olex](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/olex/32/79016_2.png) [@Olex](https://community.homey.app/u/Olex)\
**Post date:** [January 3, 2026, 7:45pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/4 "2026-01-03T19:45:44Z")

</div>

I’m using SHS on Synology NAS.  
I have several options for backup, like Synology snapshot replication and Hyperbackup.  
My concerns are which should be regarded as the safest to use.

For Synology snapshot replication:  
“For mission-critical SQLite data, Synology recommends ensuring “Application Consistency.” This typically requires freezing the application or the database before the snapshot triggers to ensure all transactions are flushed to disk”.

As I understand this, if a snapshot happens under a write, the SQlite database could be corrupted.

In my opinion, the best solution would be that Athom implements a mechanism to backup the docker installation safely.  
Maybe subscription based like the same as for the Homey Pro, @Doekse?

---

<div class="post-metadata">

**Author:** ![bwa](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/bwa/32/17852_2.png) [@bwa](https://community.homey.app/u/bwa)\
**Post date:** [January 3, 2026, 7:59pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/5 "2026-01-03T19:59:04Z")

</div>

I created a ticket for this today. The only good option is for Athom to add a new backup flow card, that creates a consistent backup/zip in a backupfolder. Then the user may decide it self about how often and how to secure it must be stored.

---

<div class="post-metadata">

**Author:** ![Doekse](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/doekse/32/109415_2.png) [@Doekse](https://community.homey.app/u/Doekse)\
**Post date:** [January 3, 2026, 8:57pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/6 "2026-01-03T20:57:50Z")

</div>

It is good to note that most platforms, like unRAID, Proxmox and more have built-in back up tools.

---

<div class="post-metadata">

**Author:** ![bwa](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/bwa/32/17852_2.png) [@bwa](https://community.homey.app/u/bwa)\
**Post date:** [January 3, 2026, 9:59pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/7 "2026-01-03T21:59:06Z")

</div>

And what existing for docker? ??

---

<div class="post-metadata">

**Author:** ![Doekse](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/doekse/32/109415_2.png) [@Doekse](https://community.homey.app/u/Doekse)\
**Post date:** [January 3, 2026, 10:02pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/8 "2026-01-03T22:02:57Z")

</div>

Where/How are you running Docker?

---

<div class="post-metadata">

**Author:** ![bwa](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/bwa/32/17852_2.png) [@bwa](https://community.homey.app/u/bwa)\
**Post date:** [January 3, 2026, 10:17pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/9 "2026-01-03T22:17:58Z")

</div>

I’m running docker on Ubuntu

---

<div class="post-metadata">

**Author:** ![Bram\_H](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/bram_h/32/52477_2.png) [@Bram\_H](https://community.homey.app/u/Bram_H)\
**Post date:** [January 3, 2026, 10:35pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/10 "2026-01-03T22:35:03Z")

</div>

I’m running Debian

---

<div class="post-metadata">

**Author:** ![Olex](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/olex/32/79016_2.png) [@Olex](https://community.homey.app/u/Olex)\
**Post date:** [January 4, 2026, 9:30am UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/11 "2026-01-04T09:30:57Z")

</div>

**And I’m running docker in my Synology NAS.** Not sure if the Synology backup solutions is safe to use with SQlite as a snapshot while writing could corrupt the database.

A solution from Athom would be highly appreciated.

---

<div class="post-metadata">

**Author:** ![Quaasteniet](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/quaasteniet/32/17209_2.png) [@Quaasteniet](https://community.homey.app/u/Quaasteniet)\
**Post date:** [January 4, 2026, 12:28pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/12 "2026-01-04T12:28:25Z")

</div>

And I’m running Orbstack on Mac Mini. 😉

---

<div class="post-metadata">

**Author:** ![bwa](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/bwa/32/17852_2.png) [@bwa](https://community.homey.app/u/bwa)\
**Post date:** [January 9, 2026, 9:18pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/13 "2026-01-09T21:18:17Z")

</div>

Looks like hot copy is not a so good idea. Just saw this in my jottacloud backup job….

pid:931 2026/01/09 22:00:15 Error uploading [#1] /data/docker-data/homey-shs/sqlite/db.sqlite-wal =\> upload: {“code”:421,“message”:null,“cause”:“”,“error\_id”:“CorruptUploadOpenApiException”,“x-id”:“U3dnV09aTlVpSmZT”}

I did open a ticket at support and got registered a backlog item for a flowcard to create a consistent backup in a own backup folder. Lest hope that will surface sooon ?

---

<div class="post-metadata">

**Author:** ![Friedhofsblond](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/friedhofsblond/32/93838_2.png) [@Friedhofsblond](https://community.homey.app/u/Friedhofsblond)\
**Post date:** [January 10, 2026, 9:19pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/14 "2026-01-10T21:19:16Z")

</div>

Hello,  
I’ve started writing a backup script. (Debian 13)  
However, when restoring, you have to remember that old and new data will be mixed.  
So, do you have to delete everything before a restore?  
I’m not working on SHS at the moment because I don’t have time right now.  
Here’s my suggestion (crontab at 10:30 PM):  
homeybkp.sh

```auto
#!/bin/bash

docker stop homey-shs

# --- Konfiguration ---
SOURCE_DIR="/home/superuser/.homey-shs" # Dein Home-Verzeichnis (z.B. /home/max)
BACKUP_DIR="/mnt/systembkp/docker/homey-shs" # Ziel fuer Backups (z.B. externe Festplatte)
DATE=$(date +%Y-%m-%d_%H-%M-%S)
LOG_FILE="$BACKUP_DIR/backup-$DATE.log"
RETENTION_DAYS=30 # Backups aelter als X Tage loeschen

# --- Skript-Logik ---

# Erstelle das Backup-Verzeichnis, falls es nicht existiert
mkdir -p "$BACKUP_DIR"

echo "--- Backup Start: $DATE ---" >> "$LOG_FILE"

# Verwende tar, um das Homey-Verzeichnis zu archivieren und zu komprimieren
# -c: Archiv erstellen, -z: gzip komprimieren, -v: verbose, -f: dateiname

tar -czvf "$BACKUP_DIR/homey-$DATE.tar.gz" \
   "$SOURCE_DIR" >> "$LOG_FILE" 2>&1

echo "Backup abgeschlossen: $(date +%Y-%m-%d_%H-%M-%S)" >> "$LOG_FILE"

docker start homey-shs

# Alte Backups loeschen (Bereinigung)
echo "Loesche Backups aelter als $RETENTION_DAYS Tage..." >> "$LOG_FILE"
find "$BACKUP_DIR" -name "homey-*.tar.gz" -type f -mtime +$RETENTION_DAYS -delete >> "$LOG_FILE" 2>&1

echo "--- Backup Ende ---" >> "$LOG_FILE"

```

 ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/1/3/132bbefaf3fa4b1ba5dc37187b1d8b9307c0642d.png)

The restore will not work because the sql.db file is incompatible!!  
The cleaning of /.homey-shs is still missing here:  
homeyrestore.sh

```auto
#!/bin/bash

docker stop homey-shs

BACKUP_FILE="/home/superuser/homey*.tar.gz"
TARGET_DIR="/home/superuser/.homey-shs"

# Prüfen ob die Datei existiert
if [! -f "$BACKUP_FILE"]; then
    echo "Fehler: Backup-Datei nicht gefunden: $BACKUP_FILE"
    exit 1
fi

echo "Entpacke $BACKUP_FILE nach $TARGET_DIR..."
mkdir -p "$TARGET_DIR" # Erstellt das Zielverzeichnis falls es nicht existiert
tar -xzvf "$BACKUP_FILE" -C "$TARGET_DIR" # x=extrahiere, z=gzip, v=verbose, f=file, -C=change directory

echo "Wiederherstellung abgeschlossen."

docker start homey-shs

```

---

<div class="post-metadata">

**Author:** ![bwa](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/bwa/32/17852_2.png) [@bwa](https://community.homey.app/u/bwa)\
**Post date:** [January 10, 2026, 9:34pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/15 "2026-01-10T21:34:26Z")

</div>

Yes, I have also created a cron script to stop, backup at date stamped zip and start again. It serves 2 purposes.

1. Offline backup

2. My SHS is killing itself every 1 or 2 days without any logs telling about why, so it might keep the server stable by this.

---

<div class="post-metadata">

**Author:** ![robertklep](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robertklep/32/160628_2.png) [@robertklep](https://community.homey.app/u/robertklep)\
**Post date:** [January 11, 2026, 5:53am UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/16 "2026-01-11T05:53:18Z")

</div>

Just a tip: your restore script stops the container, _then_ checks if the backup file exists, and it not, it exits. The container is then still stopped.

---

<div class="post-metadata">

**Author:** ![Friedhofsblond](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/friedhofsblond/32/93838_2.png) [@Friedhofsblond](https://community.homey.app/u/Friedhofsblond)\
**Post date:** [January 11, 2026, 12:40pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/17 "2026-01-11T12:40:53Z")

</div>

Ah, okay.  
I’ll add `rm -rf /path/to/folder`.  
There’s no risk; the SHS is still empty.

---

<div class="post-metadata">

**Author:** ![robertklep](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robertklep/32/160628_2.png) [@robertklep](https://community.homey.app/u/robertklep)\
**Post date:** [January 11, 2026, 12:43pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/18 "2026-01-11T12:43:18Z")

</div>

What I mean is that to me it doesn’t make sense to first stop the container and _then_ check if the file exists. It makes more sense to do it the other way around.

---

<div class="post-metadata">

**Author:** ![Friedhofsblond](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/friedhofsblond/32/93838_2.png) [@Friedhofsblond](https://community.homey.app/u/Friedhofsblond)\
**Post date:** [January 11, 2026, 1:26pm UTC](https://community.homey.app/t/homey-shs-backup-strategy-for-running-docker/148407/19 "2026-01-11T13:26:23Z")

</div>

Yes, I understand that.  
I first need to copy the desired version of homey.tar.gz from the NAS back to the home directory.  
That’s a good way to check if the tar.gz file is actually there.

But the restore isn’t working properly yet.  
Not all folders are being restored.  
I need more time.