Keeping a local copy of a synced graph

A synced graph lives as encrypted data on the sync service, which is what lets it reach every device you use. A Local Mirror puts a second, readable copy of it in a folder on your own computer: plain Markdown files, the images and attachments they use, and your graph settings.

It is a copy you own outright. Back it up with any sync service, keep it in git, read it in any other editor, or use it to rebuild the graph if you ever lose access to the original. Nothing in the folder needs EtherPK to open it.

Status: works in Chromium-based desktop browsers (Chrome, Edge, Brave, Arc, and similar) on Windows, macOS, and Linux. Firefox and Safari, including everything on iPhone and iPad, cannot hand a folder to a website yet. The Mirror tab says so on those rather than offering a button that cannot work.

Turning it on

Open the graph, then Settings → Mirror, and choose a folder. Pick an empty one, or one you are happy to hand over entirely: the mirror makes the folder match the graph, which means it also deletes anything in there that is not part of it. A folder with files already in it asks you to confirm that first.

That is the only setup. From then on the folder keeps itself up to date while the graph is open.

It is one-way

EtherPK writes to the folder and never reads back out of it. The graph on the service is always the master copy.

So editing a mirrored file has no effect, and your edit is overwritten the next time that document changes. If you want to work on the files themselves, that is a different thing: Import the folder to make a new local graph from it, described in Importing From Logseq Obsidian Or An EtherPK Export.

What ends up in the folder

<your-folder>/
  journals/2026-09-09.md
  pages/Quantum Mechanics.md
  assets/diagram.<id>.png
  etherpk/settings.json
  etherpk/graph.json

Every page is named after its title, exactly as a local graph names its own files, with only the characters a filesystem cannot hold replaced: a page called Test [[Kanban]] is Test [[Kanban]].md. The title is also written inside the file, and that is what actually identifies the document, so a file name never changes what a page is or breaks a link. If a folder was written by an earlier version of the mirror, which used lower-case hyphenated names, the first pass after updating renames those files; git shows them as renames, since the content is unchanged.

Occasionally two documents want the same file name, usually because their titles differ only by a character that cannot be in a name. The second one gets a number, like Report (2).md. Its title inside the file is untouched, so nothing links to the wrong page. The Mirror tab lists any that happened.

Attachments are copied as ordinary files, decrypted, exactly as the documents refer to them. Every attachment the graph holds is copied, including ones no document links to any more, because they are part of the graph and count against your storage. Clearing them out from Settings → Maintenance removes them from the folder too, on the next pass.

Checking on it

A small dot appears in the toolbar once mirroring, and it is the quickest way to see where things stand:

Click it for the full picture on the Mirror tab: which step is running and how far through, how much is in the folder, and when it was last checked complete. A long first pass also shows its progress as an activity, the same way an import does.

The tab reports anything outstanding, each with its own list you can open:

• Documents still syncing. Their content had not arrived yet, so their files were left alone rather than emptied. They are written as soon as they arrive.
• Attachments that could not be downloaded. Every pass tries again, including Mirror now.
• Links to attachments this graph does not hold. Usually left behind by an import that could not bring a file across. No amount of retrying will find these, so the tab names the documents holding them and stops trying. Fix or remove the link in the document. The name shown is the whole file name, including any brackets in it.

When it runs, and when it does not

Mirroring runs while the graph is open in this browser, and picks up where it left off the next time you open it here.

Nothing is lost by interrupting it. Close the tab, lose your connection, shut the laptop, come back a week later: the mirror reads the folder once, works out what actually differs, and writes only that. It does not download your documents or attachments again.

Two things are worth knowing:

• After closing and reopening your browser, it usually needs one click. Your browser does not carry folder permission across a restart on its own, so the dot turns red until you confirm access again. Install EtherPK as an app (the install icon in the address bar, or the browser menu) and your browser remembers the folder, so mirroring simply starts again on its own.
• A device that never opens the graph never updates its folder. The mirror is not a background service. If you want a nightly backup, open the graph on that machine.

If you have the graph open in several tabs, only one of them writes to the folder. Close it and another takes over by itself.

Stopping

Settings → Mirror → Stop mirroring ends it and forgets the folder. Whatever is already in there is left exactly as it is, and it stays yours.

Rebuilding a graph from the folder

This is what the copy is for. On the Graphs page choose Import, pick the mirror folder, and EtherPK builds a new graph from it. The folder is only read, never changed, and you can import it as a local graph or a synced one.

Two things do not survive the trip, by design: the graph's own identity and its edit history, and anything protected, which stays encrypted with the passphrase of the graph it came from. See Protecting Sensitive Documents for what that means in practice.

Good to know

• The mirror is per device. Another computer will not know about it until you set one up there too, and two devices mirroring the same graph produce the same file names.
• Only files that actually changed are rewritten, so a commit shows the pages you edited rather than all of them.
• The folder is managed entirely by EtherPK. Do not point a local graph at it, and do not point two graphs at the same folder, or they will delete each other's files.
• See Where Your Data Lives for how this fits with everything else EtherPK stores.