Skip to main content

Creating a Sync Backup Plan

This guide covers the current sync-plan workflow in Pluton and explains which settings are actually used when the plan runs.

The plan type is labeled Real-time Sync in the UI, but it runs on the schedule you configure. It is not a continuous file watcher.

Step-by-Step Guide​

Step 1: Open the Add Plan Panel​

From the main Backup Plans page:

  • Click + New
  • The add-plan panel opens on the right

Step 2: Basic Settings​

Configure the plan identity and method.

Plan Name

  • Choose a clear name such as Documents Sync or Project Mirror
  • This name appears in the plans list and plan details page

Backup Method

  • Select Real-time Sync
  • This creates a sync plan backed by Rclone
  • You cannot switch the plan to a periodic snapshot backup later

Click Next to continue.

Step 3: Source and Destination​

Select Source Device​

  • Choose the device that owns the source data
  • Main means the Pluton server itself
  • Remote devices appear if they are connected through Pluton Agent
  • The source device cannot be changed after the plan is created

Select the Source Path​

  • Choose the folder you want to sync
  • Keep each sync plan focused on a single source root
  • If you need to sync unrelated roots, create multiple sync plans

Current sync execution uses one effective source path per plan. Do not rely on one plan to combine multiple independent source roots.

Exclude Patterns​

Use exclude patterns to skip files or folders that should never be mirrored.

Common examples:

  • *.tmp
  • *.temp
  • .DS_Store
  • Thumbs.db
  • node_modules/**
  • __pycache__/**
  • .git/**

Exclude patterns are especially useful for caches, dependency folders, generated output, and operating-system metadata.

Select the Destination​

  • Choose the target storage
  • Optionally set a subfolder path inside that storage
  • The storage backend cannot be changed after creation
  • The destination subfolder can be adjusted later

What to expect:

  • If the destination path does not exist, Pluton creates it during setup
  • The synced destination is treated as a mirror of the source path
  • Files removed from the source are also removed from the destination on sync

Click Next to continue.

Step 4: Schedule​

Choose how often the sync runs.

Common scheduling choices:

  • Every few minutes for active work folders
  • Hourly for normal document sync
  • Daily or weekly for slower-moving data

Pick a frequency that matches how often the source actually changes.

Practical guidance:

  • Use short intervals for active files that need a fresh mirror
  • Use longer intervals for archives or slower-moving folders
  • Very frequent schedules create more sync activity, but they do not make the feature event-driven

Click Next to continue.

Step 5: Advanced Settings​

Sync plans expose sync-specific settings across a few tabs.

Content​

This tab controls how the sync behaves.

Detect file change based on

  • Choose how Pluton should evaluate whether a file changed
  • Use stricter comparison modes for critical data
  • Expect stricter modes to take longer on large datasets

File Revisions

  • Enable this to keep older copies before files are overwritten or deleted in the storage destination
  • Revisions are stored under .pluton/revisions in the destination
  • Use this when you want short-term recovery from accidental overwrites, deletes, or unwanted sync changes
  • For a full explanation of setup, limitations, and past-sync recovery, see Sync File Revisions

Important note about large or high-churn sources

  • If the sync source contains millions of files, very large directory trees, or folders that change constantly, keeping file revisions can grow revision storage extremely quickly
  • In those cases, leaving File Revisions disabled is usually the safer default unless you have carefully planned retention, storage capacity, and cleanup behavior
  • If you still need revision protection for a busy dataset, keep retention short and review the revision skip threshold so very large change cycles can avoid creating another full wave of revision data

Good use cases for enabling File Revisions

  • user-created documents that are edited often and need quick rollback
  • source code or project files where accidental overwrites are a realistic risk
  • design files, spreadsheets, reports, or similar work products that benefit from short-term version safety
  • moderate-size sync plans where change volume is predictable and storage growth is manageable

Remove revisions after

  • Revision retention is age-based, not count-based
  • Use a retention value that matches how long you want recent versions available

Revision skip threshold

  • Pluton estimates the size of a run before the real sync starts
  • If the amount of changed data exceeds this threshold, the run can skip creating revisions for that cycle
  • This helps prevent very large change sets from exploding revision storage unexpectedly

Max tracked file changes

  • Controls how many file-change records Pluton keeps for a sync task
  • Lower values reduce metadata size
  • Higher values keep more visible change history in the UI

Performance​

This tab currently exposes:

  • maximum transfer size
  • multi-thread cutoff
  • multi-thread stream count
  • multi-thread chunk size
  • multi-thread write buffer size

Adjust these only if you have a clear throughput or storage-backend reason to tune them.

Integrity​

  • The UI lets you configure sync integrity preferences
  • For sync plans, integrity checks are currently run manually from the plan page rather than on an automatic schedule
  • Use Check Integrity from the plan actions when you want to verify source and destination contents

Notifications​

  • Configure notifications for sync outcomes as supported by your deployment
  • Failure notifications are usually the most useful for frequent sync plans

Misc​

  • Add tags to organize related plans

Step 6. Create the Plan​

Click Create Plan after reviewing the configuration.

What Pluton does next:

  1. Validates the selected source and destination.
  2. Registers the sync schedule.
  3. Creates the destination path if needed.
  4. Creates .pluton/revisions if revisions are enabled.
  5. Starts the initial sync immediately.
  6. Opens the plan details page.

What the First Sync Does​

The first run is usually the longest one because Pluton has to create the initial mirror.

During this run:

  • files are copied from the source to the destination
  • progress appears in the plan details page
  • change metadata is recorded for the sync task
  • later runs transfer only what changed

After the plan is created, verify the behavior with a small test:

  1. Confirm the initial sync completes successfully.
  2. Open the destination and verify the folder structure looks correct.
  3. Modify one file in the source and wait for the next run, or trigger Sync Now.
  4. Delete one non-critical test file from the source and confirm the destination follows the change.
  5. If revisions are enabled, confirm a previous version appears under the revisions area after an overwrite or deletion.

Planning Tips​

Keep Plans Narrow​

  • One source root per plan is the safest approach
  • Split unrelated data into separate plans for clearer history and simpler troubleshooting

Use Revisions Selectively​

  • Enable revisions for documents, code, and other human-edited files
  • Consider disabling revisions for caches, exports, or easily regenerated assets

Tune the Schedule to the Workload​

  • Very short intervals are useful only when the source changes frequently
  • For quieter folders, hourly or daily syncs usually make more sense

Pair Sync with Backup for Critical Data​

  • Sync gives you a current mirror
  • Incremental backups give you historical recovery
  • Critical data often benefits from both

Common Mistakes to Avoid​

  • treating sync as bidirectional replication
  • expecting the sync plan to watch files continuously without a schedule
  • packing multiple unrelated source roots into one plan
  • syncing caches or build output that should be excluded
  • assuming revisions are count-based instead of age-based

If Creation Fails​

Check the usual causes first:

  • the source device is offline
  • the source path does not exist or is not readable
  • the destination storage is unavailable or misconfigured
  • the chosen destination path is not writable

If the plan is created but the initial sync fails, open the plan logs and verify source access, storage connectivity, and exclude patterns.

If the first run is simply slow rather than failing, check network and storage performance, review your performance settings, and remember that later syncs are usually much smaller than the initial mirror run.

Next Steps​

Remember: Test sync behavior with a small folder before syncing large or critical datasets.