Home/Featured/Sync & Backup
📌 Featured · Sync & Backup MN 4 / Settings → Backup & Restore

Put your notes in a reliable backup location.
Nothing lost. Nothing scrambled. Cross-device.

MN offers 4 automatic backup locations (Local / WebDAV / Baidu NetDisk / Google Drive) + full export bundles + CloudKit cross-device sync. Below: how to set each up, capacity guidelines, and what to do when things go wrong.

📁 Local Folder
Back up to a local directory — no network needed, rock-solid.
 🗄️ WebDAV / NAS
Your own Synology / self-hosted / corp WebDAV. Fully controlled.
 ☁️ Cloud Drives
Baidu NetDisk / Google Drive — QR or OAuth.
 🔁 Cross-device sync
iCloud CloudKit — iPad ↔ Mac auto-aligned.

SETUP · Configure each channel

5 ways to store your notes — set up one at a time.

Each card below is one storage location or export method. All share one entry point: open MN on iPad / iPhone / Mac → Settings → Backup & Restore.

📁 Auto-backup to a local folder

No network · Rock-solid · No cloud quota

  1. Open MN → Settings → Backup & Restore
  2. Scroll to "Backup Location", pick "Local Folder"
  3. Choose where to store (on iPad, a folder in the Files app; on Mac, anywhere in Finder)
  4. Pick a frequency: Manual / Hourly / Every 6h / Every 12h / Daily / Weekly

Backup format: .marginbackupall. You manage the file — store it wherever you like. Nothing gets uploaded automatically.

🗄️ Auto-backup to WebDAV / NAS

Synology / self-hosted / corp WebDAV / Jianguoyun

  1. Settings → Backup & Restore → Backup Location → "WebDAV Server"
  2. Under "WEBDAV CONFIGURATION", fill in Server URL (e.g. https://dav.example.com/), Username, Password
  3. Tap "Test Connection" to verify it can reach the server
  4. Pick a frequency — MN will push backup bundles on your schedule

Supports HTTPS with self-signed certs; for Jianguoyun use an "app password" not your login password; Synology / QNAP built-in WebDAV works with the regular account.

☁️ Auto-backup to Baidu NetDisk

China-region preferred · Large capacity · QR login

  1. Settings → Backup & Restore → Backup Location → "Baidu NetDisk"
  2. Tap "Sign in to Baidu NetDisk" — QR code login first (scan from the Baidu NetDisk mobile app); account / password login is available in the same panel
  3. After authorization, return to MN and pick a frequency
  4. The first run uploads the current Study Set / card deck content as a full bundle (slow); subsequent runs only push changes

Bundles are placed in a dedicated MarginNote folder in your Baidu NetDisk. Standard accounts have plenty of room for multiple full Study Set backups.

☁️ Auto-backup to Google Drive

Overseas preferred · OAuth · Cross-device access

  1. Settings → Backup & Restore → Backup Location → "Google Drive"
  2. Tap sign-in to launch Google OAuth — authorize MN to write to its dedicated folder in your Drive
  3. Return to MN and pick a frequency
  4. Requires reliable access to Google services; after first authorization the token auto-refreshes — no repeated logins

Bundle size limited by your Google Drive quota (15 GB free shared with Gmail / Photos). Consider toggling "include original PDFs / videos" — notes-only data is typically < 200 MB.

💾 Manual Full Export bundle

Long-standing · Manual · Best for migrating to a new device

  1. Settings → Backup & Restore → "Full Export" card at the top
  2. Three granularity options:
    • Database + All Documents + Version History — full archive, best for moving to a new device
    • Database + StudySet Documents — only PDFs tied to Study Sets, saves space
    • Database Only — note metadata only, no PDFs
  3. Exports MarginNoteBackup(yyyy-MM-dd-HH-mm-ss).marginbackupall to any location
  4. Restore: install MN on new device → Settings → Backup & Restore → pick the local .marginbackupall file → import

This mechanism predates the MN 4.3 architecture. Auto-backup is for continuous safety; Full Export is good for occasional manual archives to an external SSD.

📌 Settings entry: MN → Settings → Backup & Restore. You can enable multiple at once — recommended: at least "Local + one cloud" — one copy you control, one copy off-site.

MarginNote iPad Settings · Backup & Restore panel (English UI): Full Export (three granularities) + Auto Backup with Backup Location options (WebDAV / Local / Baidu NetDisk / Google Drive) + Baidu NetDisk Configuration + Backup Frequency
The real Settings → Backup & Restore panel (iPad). Full Export (three granularities), Auto Backup (four locations), and WebDAV configuration are all on this one screen.
Long-standing · Cross-device sync

SYNC · iPad ↔ Mac auto-aligned

Use iCloud CloudKit to auto-sync between your devices.

This is Apple's own iCloud sync — no third-party account needed. It's different from "backup": CloudKit keeps your iPad and Mac aligned with the current latest state; backups store historical snapshots in a place you can retrieve from later. Run both for the best safety net.

How to enable

Settings → Cloud Sync → choose CloudKit Sync.

Uses whichever iCloud account is signed in; all devices on the same Apple ID join automatically.

When to use / skip

Use it: iPad + Mac alternating workflow; want to pick up where you left off.
Skip it: single-device users; very large libraries with full iCloud quota.

Reset sync cache

If you see hangs or anomalies: Settings → Cloud Sync → Reset Sync Cache — all data gets re-compared (has a confirmation prompt; tapping it doesn't lose data).

Per-Study-Set enablement

Choose "Enable manually per Study Set" or "Enable automatically": manual gives finer control (less-important sets don't eat quota); automatic suits "new set = synced set" users.

Real value when things go wrong

Network down / conflicts / quota full / cross-account — all have fallbacks.

A sync & backup system's real value isn't when it works — it's when it breaks. This section maps recovery paths for every failure mode, so you know which button to press when things go sideways.

Sync status bar

Checking for updates / Preparing download / Downloading (n/m) / Preparing upload / Uploading (n/m) / Sync completed / Sync failed

Each state corresponds to a real sync stage — not vibes, actual progress.

Conflict UI (Cloud Drive Sync)

On detected version change: three choices — Use Remote / Merge / Keep Local. Default is "Merge", and a pre-merge backup is auto-created.

Reset Sync Buffer

If CloudKit Sync gets stuck or behaves oddly, you can reset the sync buffer in Settings → Cloud Sync — all data re-compares. Nuclear option, with second confirmation.

Manual Sync Backup

Every manual sync auto-backs-up the local DB to Documents/ManualSyncBackups, keeping the latest 5. Even if a conflict gets ugly, the last 5 manual-sync states are recoverable.

Manage CloudKit Zones

If you stop using CloudKit Sync and want to clear cloud data, the settings let you manually delete CloudKit zones — frees iCloud quota, local data unaffected.

Object Pool GC + Baseline Repair

The Cloud Drive Sync object pool exposes manual GC + baseline-version repair — fixes orphan objects and missing baselines that long-term usage can produce.

Honest boundaries

Some things MN does not promise.

"Never lose data" sounds great — but no engineering system can actually promise that. MN chooses not to overclaim, and instead tells you exactly what each layer of protection does.

Not realtime collab (CRDT / OT)

Sync is eventual consistency based on change tracking — multi-device align in seconds to minutes. It's not Google Docs character-level co-editing. MN doesn't do realtime collab.

Not full Git three-way merge

Cloud Drive Sync's merge is object-level by manifest / hash / timestamp — better than last-write-wins, but no full common-ancestor lookup yet. So "git for study notes" is a design analogy, not literal git equivalence.

Local protection requires snapshots

"The architecture itself protects data" relies on auto-snapshots being on (the default). If you manually disable auto-snapshot AND have never run a manual / baseline snapshot, the state from one second before a crash is not guaranteed by the code to be recoverable. What's recoverable is "the most recent complete snapshot".

No zero data loss promise

Cloud outages, full device failure, Apple ID issues, accidental deletes — all of these can happen. The new architecture + Auto Backup + Full Export reduce risk through layered protection, but no "absolute safety" claim. Recommended: periodic Full Export + one copy somewhere you control (external SSD / your own NAS / a cloud account different from your daily one).

About versions: the "new data architecture" described on this page was introduced in MN 4.3. "Cloud Drive Sync" is the next step built on that architecture, currently Coming Soon — the rollout schedule follows the official release notes.

COMING SOON MN 4.3+ ARCHITECTURE

Next-gen · Sync

Cloud Drive Sync: the next-generation cross-device sync.

The next-generation sync system — mutually exclusive with CloudKit Sync (pick one in Settings). MN 4.3 rebuilt sync from the ground up — structural issues like "mind map corruption" and "handwriting layer mismatch" don't occur in the new sync. Technical details in the "FOR THE CURIOUS" section at the bottom.

Supported cloud-drive backends (3)

iCloud Drive · Baidu NetDisk · Google Drive

OneDrive / Dropbox interfaces are reserved in code (currently hidden); WebDAV is backup-only, not in the Cloud Drive Sync options.

Atomic unit = Manifest

Every change creates an immutable snapshot: versionNumber + deviceId + content hash all live in the manifest.

Key difference: remote transfer can still half-fail, but it shows as missing objects or corrupted index (repairable) — never as "layout pointing to non-existent nodes".

Conflict UX (user-decided)

On a version conflict the UI offers three choices: Use Remote / Merge (default) / Keep Local.

Before merge, an automatic Pre-merge Backup is created — even if you pick wrong, the original is intact.

Cross-device recovery

First-launch on a new device pulls remote snapshots and reconstructs local data per manifest; optionally pulls original documents (PDF/Video) too.

Object index can be rebuilt; missing remote objects can be repaired via baseline-repair.

📌 Current state: code complete, UI gated by internal flag mn5SyncSupported; rollout schedule TBA.

FOR THE CURIOUS Why did MN 4.3 rebuild the data layer?Tap to expand ▾

This section is for engineering-minded readers — what the MN 4.3 data architecture is, why it was rebuilt, and how it differs from CloudKit-era sync. This doesn't affect day-to-day use — just follow the steps above and you're set.

MN 3.x → 4.2: CloudKit Sync (record-level) + Full Export → Since MN 4.3New data architecture · Auto Backup · Local integrity → Coming Soon: Cloud Drive Sync

Architecture

MarginNote data architecture and three application surfaces Local data flows into the data architecture (BackupStorage content-addressed object pool + Manifest versioning), which is reused by three applications: local integrity / Auto Backup / Cloud Drive Sync (Coming Soon). Full Export and CloudKit Sync are legacy mechanisms preserved for compatibility. Local MarginNote Data Study Sets · Cards · Excerpts · Mind Maps · Handwriting · Reviews · Docs SINCE MN 4.3 Data Architecture · BackupStorage + Manifest Apply git's versioning approach to study data Content-addressed pool SHA-256 + atomic write Manifest versioning versionNumber + deviceId SQLite transaction Atomic snapshot metadata REUSED IN THREE PLACES ① Local Integrity DEFAULT ON 5-min idle auto-snapshot Pre-sync / pre-conflict snapshot ② Auto Backup AVAILABLE Scheduled · incremental · versioned 4 destination backends ③ Cloud Drive Sync COMING SOON Manifest-level cross-device 3 cloud-drive backends → Crash / wrong edit recovery No sync, no remote backup needed → Any past version restorable Local · WebDAV · Baidu · Google → Multi-device consistency (snapshot) iCloud Drive · Baidu · Google LEGACY · PRESERVED FOR COMPATIBILITY Full Export Manual one-shot full archive, separate from new architecture .marginbackupall · 3 granularities Still preferred for migration / long-term archival CloudKit Sync Legacy record-level sync (since 2015) CloudKit private DB · same Apple ID devices ↔ Mutually exclusive with "Cloud Drive Sync" — pick one Blue = MN 4.3+ new architecture Yellow = Legacy (MN 4.2 and earlier) Dashed = Coming Soon

At the center is the data architecture itself (introduced in MN 4.3), reused in three places: local integrity safety net / Auto Backup / Cloud Drive Sync (Coming Soon). Below, Full Export and CloudKit Sync are legacy mechanisms (MN 4.2 and earlier), preserved alongside the new architecture.

MN 4.3+ · Foundation

NEW · Since MN 4.3
Apply git's versioning approach
to your study data.

Since MN 4.3, MarginNote introduced a versioned data foundation — not just "backup" or "sync", but a foundation reused in three places. This is the real architectural upgrade in this generation.

01

Object pool

Content-addressed SHA-256

Every piece of data is addressed by SHA-256 hash — identical content stored once. Files use writeToFile:atomically:YES; on index-insert failure, the just-written file is rolled back.

  • Loose objects + Pack files (>1000 / >50MB triggers pack)
  • Index can be rebuilt from objects
02

Manifest

Snapshot-level atomic unit

Each Study Set snapshot is a Manifest: versionNumber + deviceId + content hash + dependency graph. Sync and recovery operate on manifests, not fields or records.

  • This is the new architecture's core — a Study Set fully succeeds or fully fails
03

SQLite transaction

Metadata atomic commit

Snapshot metadata is committed inside a SQLite transaction. Either the snapshot lands fully, or it never appeared — no half-committed manifests.

  • BackupSnapshots_v4.sqlite (schema v6)

⚠ This isn't a single global ACID transaction across CoreData + object pool + snapshot DB. It's "object pool atomic + manifest atomic" as two separate atomicities. The user-facing experience is a version-control safety net, not a database-level ACID journal.

MN 4.3+ Application ① · Local integrity

NEW · Since MN 4.3
Without sync, without external backup —
the architecture still protects your data.

"Lost handwriting", "mind map corruption", "notes vanished after crash" are MarginNote users' long-standing pain points. The new architecture catches edits as snapshots locally — no remote destination required.

DEFAULT

5-min idle snapshot

Edit a Study Set → marked dirty → if editing pauses 5 minutes → an immutable snapshot is committed locally.

  • Pre-sync auto-snapshot (default ON)
  • Pre-conflict auto-snapshot (default ON)
  • Post-sync snapshot (default OFF, avoids redundancy)
RECOVERY

Objects + index repairable

If object content fails hash verification — bad sectors, corrupted file — verifyIntegrity + rebuildIndex can rebuild the object index.

  • UI: Repair Missing Baseline Versions (Recommended) — only shown when uncovered Study Sets are detected

⚠ Honest boundary: the protection above relies on auto-snapshots being on (the default). If you manually disable auto-snapshot AND have never run a manual / baseline snapshot, "the state from one second before the crash" is not guaranteed by the code to be recoverable. What the architecture gives you is recovery to the most recent complete snapshot, not lossless per-keystroke versioning.

MN 4.2 and earlier vs MN 4.3+ · Data atomicity

Same "sync failure" —
old architecture corrupts, new architecture misses objects.

These two failure modes have completely different recovery costs. "Corruption" requires the user to manually identify which data is wrong, possibly to roll back or hand-fix. "Missing objects" is visible, locatable, automatically repairable — it tells you which hash didn't download fully and re-fetches. That's the difference MN 4.3's new architecture brings.

Dimension MN 4.2 and earlier (CKRecord-level) MN 4.3+ (Manifest-level)
Write atomicity CoreData save has atomicity, but sync layer's units are Topic / BookNote CKRecords Objects use writeToFile:atomically:YES; index-insert failure rolls back the just-written file; snapshot metadata in SQLite transaction
Sync atomicity
(all changes of one Study Set)		 CKModifyRecordsOperation.atomic = YES only covers current batch; a Study Set is split across batches due to resultsLimit / media size The manifest is the visible unit; remote transfer can half-fail but shows as missing objects (repairable), not field corruption
Conflict unit record / field-level, relies on CloudKit save policy and changedKeys snapshot / manifest level, committed with versionNumber + deviceId + manifest hash
Half-failure state CKErrorPartialFailure → tracked failed/missed records; may use atomic = NO to clean reference errors. User feels: mind map corrupted Object pool may have missing objects or damaged index, but verifyIntegrity + rebuildIndex recover. User feels: prompted to re-sync objects
Rollback No StudySet-level immutable manifest to roll back to; relies on legacy backups or manual conflict handling Restore to any historical snapshot; baseline repair fills missing version coverage
Content hash verification Uses hashOfDataCRC for diff only — not whole-StudySet manifest content addressing Objects and manifests fully SHA-256 content-addressed
Cross-device consistency guarantee CloudKit record-level optimistic locking; full StudySet consistency must be reassembled across multiple records / batches Manifest / snapshot-level "version commit" — but still not CRDT, not realtime collab

Related

Look at these neighbors

Card Axis →

"One object, three renders" — sync & backup only need to protect one underlying object because all three views share it.

Immersive Mode →

Introduced in 4.4. Read / Write / Recall toggle — every action you take is protected by the sync & backup layers.

What's New →

Sync & backup evolution timeline — from MN3 through MN4 CloudKit and into next-gen Cloud Drive Sync.

Not just usable — trustable.

Download MarginNote 4 and put your notes into a tool that treats data safety as an explicit engineering job.

App Store → Mac DMG →