Plain text merges better than binary, but two devices editing the same subtree still collide, and a synchronized copy is not a backup.
Plain text improves inspectability and merging; it does not eliminate concurrent-edit conflicts. Two devices can edit the same subtree, and a sync service may create conflict copies or silently choose a winner. Availability, history, backup, and confidentiality are separate goals, and one tool rarely supplies all four.
Sync choices
| Method | Strength | Main risk |
|---|---|---|
| Git | history, branches, meaningful diffs | manual discipline; conflicts; no automatic mobile UX |
| Syncthing | direct continuous replication | concurrent conflicts; device availability |
| Cloud drive/WebDAV | broad device support | provider behavior, latency, privacy, conflict copies |
| Direct remote editing/TRAMP | one authoritative remote file | network dependency and latency |
A robust pattern separates working replication (Syncthing, WebDAV, or a cloud drive keeps files available on current devices), version history (Git or filesystem snapshots record intentional states), and backup (recoverable, preferably encrypted copies on a separate failure domain, including an offsite copy). If ransomware, accidental deletion, or a faulty sync client can immediately propagate to every copy, replication has not provided backup. If the only key lives on the failed laptop, encrypted backup has not provided recovery.
Avoid editing the same file simultaneously on two devices. Let synchronization finish before opening and after closing. Commit coherent changes. Review conflict files as text; never bulk-delete them before comparison.
Conflict protocol
When a conflict happens, work in order: stop synchronization on the affected devices, copy every conflicting version into a recovery directory, and identify the common base from Git or backup. Then merge structurally: preserve complete subtrees, drawers, and timestamps, and check for duplicate IDs and repeated entries. Open the merged file in Org, cycle visibility, run link checks, refresh Agenda, commit the resolution, and resume one sync path at a time. Line-based automatic merging can place a property drawer beneath the wrong heading while still producing syntactically valid text, so structural review is not optional.
Mobile reality in 2026
Mobile support is third-party. Orgzly Revived is an actively maintained GPL-3.0-or-later Android app; v1.23.0 shipped 12 August 2026. beorg is a proprietary, actively updated iOS app (2026.8 in July 2026) oriented toward agenda and tasks. Plain Org is a proprietary iOS editor still available, but its latest verifiable release is 1.10.0 from February 2025, so current activity is uncertain. No client implements every Org behavior. Begin with copies of two representative files, disable simultaneous desktop editing, and observe diffs after each mobile action (checkbox toggle, reschedule, property edit, note creation, attachment). Adopt the app only if its transformations are acceptable and recoverable.
Encryption and restore testing
org-crypt encrypts selected subtrees with GnuPG, typically marked by a configured tag, and protects ciphertext at rest while the key stays secret. It does not protect headings left outside the subtree, filenames, Git history containing earlier plaintext, swap and backup files, the clipboard, or exports made while decrypted. Passwords, recovery codes, private keys, and production credentials belong in a dedicated secret manager. Git history preserves deleted secrets: removing a credential from the latest file does not remove it from old commits or remotes, so rotate the credential first, then remediate history.
A backup is a claim until restored. Quarterly, restore to a clean temporary location, verify file counts and checksums, open representative files, resolve IDs, display attachments, build one export, and confirm GPG decryption using documented recovery material. Record duration and failures somewhere outside the backup set.
Summary. Availability, history, backup, and confidentiality are separate goals that one tool rarely supplies together. A three-layer design plus tested restores and a structural conflict protocol keeps an Org knowledge base recoverable.
Exercises
- Basic: Initialize Git for a set of sample Org files and inspect one readable diff. Then explain in a sentence why those synchronized copies are still not a backup.
- Practical: Simulate a conflict on copies of two files and resolve it structurally, preserving complete subtrees, drawers, and timestamps, without data loss. Restore the sample directory to another location and open it without changing configuration.
- Advanced: Write and test a restore procedure from an offsite backup and measure recovery time. Then run a tabletop exercise for three failures: lost laptop, compromised cloud account, and corrupted sync database.