Syncthing configuration -- (selective) syncing to many devices

The challenge of configuring Syncthing has come up several times, including This thread. It was starting to get technical there so I thought we could use a dedicated thread for the nitty gritties.

There, I noted that I’d experimented with the API and that I’d write more when I’d figured it out – that will be in this thread.
@fender replied with some details on their setup – which I will respond to first.

The gist was:

Things I want synced to multiple locations / devices live in my 9* area of JD
Single means only one generation / 1 copy
Multi means multiple generations with autocleanup / versioned backups back in time

2024-07-16 22_59_11

Do I understand correctly:

  • this is primarily meant for ‘archives’ that you want distributed? If not, I would find this very limiting since the category name and location would be dictated by the tool rather than their content.
  • I suppose it would be less limiting if you want to make a clear distinction between ‘archival’ material that hardly changes, versus hot stuff which might be more specific to each device. In my setup, I mix those up a lot more.
  • do you move things around ‘manually’ using your ‘transfer’ folder? I can actually see some benefit to that. You always know when something is being moved to another physical machine. I think I want, though, to synchronize working files automatically. I’m also sharing this system with someone else. (though we have used a ‘inbox’ sync folder for each of us in the past … might be an idea to use that more).

I have used the following backup strategy in the past:

  • one central server ( raspberry pi)
  • multiple portable devices (laptops, phones)
  • the server is a peer of each of the portables with continuous sync
  • every night, the server’s copies are backed up incrementally

I did this because of the hassle of when to run backups on my laptop: I don’t want it on all night, and I never make time to run backups during the workday.

Next, I want to write about using the .stignore file. But first, back to work.

Looking forward to this!

This is how we run JDHQ. While Syncthing has no concept of ‘the primary copy’, I do. And it’s on the massive hard drive attached to the always-on Mac mini in the cupboard.

So that instance has a different backup strategy, and different Syncthing versioning rules. So far this has worked really well for us. We were burned with other sync solutions and I love how pure Syncthing feels.

1 Like

An attempt to describe / outline the backup regime - where Syncthing is part of it:

  • 0a

    • Main point of “COMMON” folder in Syncthing = path of least resistance and friction:
      • Sometimes I have my tablet or a phone (Android), and I need to move a PDF or some file and access it from another device or computer.
      • I use the COMMON folder to traffic such files ad-hoc between devices.
      • I use OpenVPN and/or Tailscale to gain access to home network if I’m out and about / outside my LAN.
  • 0b

    • I use Hyper Backup to selectivly create backups from other structures in the JD file system. Some more frequent, some less frequent, some encrypted. These backups are then put in the 9* area.

    • The [93] Cold_storage_single is my dumping ground. I only have a single copy of what in there. If the harddrive or NAS fails, life goes on. The alternative would be to delete those files.

  • 1

    • My JD folder structure (approx 90% cured/matured at this point - still finding my ground with some areas/categories - but mostly happy):
      • JD\

* JD_B\ (*technical reason - since this is backup* *target* *, it is split into separate "Shared folder" in Synology NAS - b for backup*)

2_index2

  • 2

    BACKUP - intent / design / what should it cover:

    • Trying to protect against / reason for backup / the most likely bad things to happen:

      Most likely, limited conseqences (probably fixable)

      • Scenario 1:
        • “Anti-Homer Simpson” (d’oh-moments) (human) and/or random disk/system/hardware failure on device X
          • NEED
            • Frequent backups
            • Multiple generations of backups / be able to go back in time if needed
          • TARGET
            • Hot storage, single and multi
          • IMPLEMENTED HOW
            • Syncthing, with and without versioning

      A bit less likely, but severe consequence if allowed to happen unmitigated / without prevention measures

      • Scenario 2:
        • Ransomware / malicious file system encryption
          • NEED
            • To keep files offline / disconnected - but with regular updates of files that don’t change too often
          • TARGET
            • Cold storage_backedup
          • IMPLEMENTED HOW
            • Remote control power > I have USB drives/USB docking stations that are connected w USB to the NAS servers - they have their power in remote control sockets. I turn them on when I want to sync or access files. Most of the time they are powered off.

3_remote-control-socket

  • USBCopy (Synology) *described further down - (automagically copy files to external USB drive when connected or powered on)
    * rsync (Synology) *described further down

    Hopefully even less likely, but very bad consequence

  • Scenario 3:

    • Fire, natural disaster - or other worst case scenario that destroys on-site drives and systems (main point; off-site backup)
      NEED
      * Worst-case scenario, all hardware is destroyed - everything except backups kept off-site is gone
      * (Don’t really like the idea of pushing stuff into the cloud, but with encryption I can live with it. I don’t consider myself naive, hence I understand that eveything is theoretically possible to decrypt - but not without effort. Encryption provides a basic level of comfort pushing personal data into the cloud.)
      • Also;
        * Small form-factor external harddrive with encrypted copy of files, kept off-site (typically in car or office)
        • TARGET
          • Offsite, cloud and/or external drive
        • IMPLEMENTED HOW
          • Hyper Backup (Synology) (create scheduled encrypted backups from selected folders)
          • USBCopy (Synology) (automagically copy files to external USB drive when connected or powered on)
          • Cloud Sync (Synology) (automagically upload encrypted backups to cloud services, preferably free tier Google Drive and/or OneDrive)
      • Hopefully doesn’t happen in my lifetime
        • Scenario 4:
          • Global extinction event
            • NEED
              • Don’t think I need backup for this one.
              • No efforts made. :volcano:
    • Goal
      • Automate as much of it as possible (least amount of manual work / operations)
        • (I’m lazy - but I like running a tight ship, don’t like surprises)
      • Keep it as simple as possible
  • 3

    • Setup (not all the details, but a quick look / overview - for reference | impression)
      • Hyper Backup (Synology NAS)

  • Cloud Sync (Synology NAS)

  • USB Copy (Synology NAS) > can set trigger conditions and tasks - example; run task if external drive is connected or powered on

4_USB-COPY

  • rsync
    • I use built in rsync clients on Synology NAS servers, Hyper Backup with latest, older clients with the older

NAS servers
* DS124 < main server, always on/powered - runs Syncthing
* DS209 < for rsync backups, runs RAID1 w 2 drives, always on, powered
* DS107+ < for less frequent rsync backups, poweroff most of the time, wakes on schedule

  • Sorry for long post…
    • If anyone has any simplifications or things I’ve missed that should be covered, please hit me up

Oh yeah - forgot… just for completeness of the overview.

For full system backups (with restore possibility, also to other hardware/new drives):

  • Was a long time fan of Acronis True Image, until they went for a subscription-only business model. I still have a perpetual license that I still enjoy that does the trick.

  • For other (Windows) systems - (lower priority, but still don’t want to start from scratch if I need to re-deploy) - I use AOMEI Backupper Standard (free).

You do future alien archaeologists a dis-service!

1 Like

Thanks for the detailed description @fender! I may be missing something, but it looks like most of your JD system isn’t managed by Syncthing?

Syncthing awkwardness – the limitations of .stignore

Don’t get me wrong – I use Syncthing and in general, for what it does, it works really well.
But there’s something I’ve run into in the past which is only exacerbated when dealing with a JD system.

that is: how do you only sync certain parts of your tree to various devices?

Example from my situation: I want to share a JD system with my partner, but there are a few folders which are specific to each of our businesses which do not need to be/should not be synced to the other person’s laptop.

Another example: I only want a few folders from my JD system on my phone, the whole thing takes up too much space. (this is not specific to JD – the same could apply with a photo or music collection, for example).

Sync each folder seperately

One solution is to make each category or even ID folder its own Syncthing folder. You can then select, on each folder, which devices it gets synced to.

For categories I can kind of see that working … but at the ID level? you’d have up to 10,000 folders if you stuck to classic 10.10.100 JD … not feasible.

I think a mix of syncing areas and categories might be realistic. But managing it might become confusing.

Limitations of the .stignore file

then there’s the .stignore file. Which seems like it would be the way to do this, but there are issues.

The Syncthing documentation says the .stignore file is for controlling sync ‘to (or from) other devices’. Sounds good, but … ‘other devices’ means all other devices are treated as one. What that means: you only have one on/off switch for all outgoing/incoming data. You can’t say:

#in .stignore on laptopA

*.git        #applies to all devices

[laptopB]    #applies to laptopB
19.22        #sensitive client files

[phone]      #applies to phone
45           #full of big archives

I am, personally, rather surprised that this a) is not possible, and b) doesn’t come up in my extensive searching through online discussions. It seems to me like the most obvious thing …

EDIT the problem is more or less the same as what people are talking about when they ask for ‘selective sync’ and point to other services like Dropbox or Rsilio which sync a pointer file to be downloaded on user request from the GUI. that, however, is GUI based and is also controlled from the receiving end – see next section.

A solution – .stignore on the receiving device

there is a way to make this work. It is, unfortunately, not secure, strictly speaking. Whether that’s a problem kind of depends.

The solution is to put .stignore files on the devices where you want to exclude stuff. So on laptopB you could put 19.22 and on phone you could put 45 and these devices won’t download stuff that matches those patterns.

This solves the problem of storage size.

My partner and I did this in our previous shared Sync folder for mobile devices: on our phones, we ignore everything with * and then allow a subset with !*.mob.* so that if we rename a file with .mob. in the name it will get synced.

This isn’t really secure, though, because if someone gains access to the device, they can remove the .stignore file to start receiving everything. Whether that is acceptable depends on your situation. I wonder, for example, if it would strictly pass EU data protection regulation if customer data is involved. (Actually, strictly speaking, relying on the presence of an ignore file is probably not best practise anyways, even if it worked as I desire).

So I don’t actually know of a really good solution to this.

I think the best way forward might be a mix of the two methods:

  • .stignore on receiving devices for non-sensitive stuff, to reduce data usage
  • put sensitive data in a separate area or system and make that a separate syncthing directory.

I’d be sad about that last point, though, because it would mean creating a high-level container just for the sake of making Syncthing work well, after all my hard work at getting everything comfortably down to half a JD system.
I think I could live with activating two of my four currently unused Areas. One each for my partner and me, for sensitive business-related information. Then I would have eight folders to manage in Syncthing: six for our shared setup, and two for each of our two businesses, which would be almost empty since those are currently two categories under 00.

Mostly the “Hot_storage” folders are done by Syncthing, pulling data from various sources.

I see I’ve fallen into a setup where the structure is dictated by the tools.

@hans Thanks for an inspiring post about .stignore

  • I had a tumble with it at some point when trying to do only certain files, but I struggeled to make it work the way I wanted (probably messed up the pattern and syntax).

  • Read the docs, and your post gave me the urge to give it another go.

I am curious about having a global file that syncs to all devices, implemented by having this in the root .stignore

// Usage: Add the line below to all .stignore files for each Syncthing node
// #include .stglobalignore

and then adding all patterns in .stglobalignore (which is synced to all devices)

(example here)

I am aware there are pitfalls and an existing long discussion, but I might experiment with it. Will report back if I find it useful.

I could never get this working. Let me know if you can.

This seems like an elegant solution that I would love to see in Syncthing. I think it would be cool if [phone] and [laptopB] were user-defined device or ignore groups—devices would all belong to one group (root group being default) but they could choose group names based on the headers in the ignore file.

Thanks also for pointing out the security issue—I hadn’t thought of that. For me, I just sync my entire Documents directory with its JD system between all devices, mobile or not. I guess I’ve been lucky in that I’ve never run out of space on my phone. I sync my mobile phone photos to my computer with Syncthing and archive them on a yearly basis.

I now have the following up and running:

What I wanted to do:

  • I have a “todo” file in Logseq (it’s under 00-09 System in JD).

  • Instead of having a separate “todo” app for the phone - I wanted to share and sync only this file (TODOS.md) file with Android devices, so I can tick things off with the Logseq android app while on-the-go - and then sync it back to “the master”.

“Master device / main system (ON when used) - with Syncthing and Logseq”

.stignore of Send&Receive shared folder

!/TODOS.md
*

(Result: shares only this single file and ignores everything else in the share folder.)

“Always online server (always ON)” - with Syncthing

no .stignore for this folder

(this is just to ensure that some device is always “online” with the lastest version - regardless of whether it’s the Android devices or the master device that is being used on that particular .md file at the moment)

“Android device(s)” - with Syncthing and Logseq app

!/TODOS.md
*

(to avoid other stuff being synced back to “always online server” - it would not go back to the “master” anyway because master has it’s own .stignore )

(I will not be editing the same .md file on both devices simultaniously. I’m either “on the go” or using the “master device” - so sync conflict of this single file is a less likely edge-case)

So far, working as desired.