Skip to main content

Storage Sync Plans Introduction

What is a Storage Sync Plan?​

A storage sync plan keeps a copy of one storage inside another storage.

You pick a path in a source storage, pick a destination storage, and set a schedule. From then on, Pluton keeps the destination matched to the source: new objects are copied, changed objects are replaced, and objects deleted at the source are removed from the copy. The result is a browsable duplicate that you can open, download, or restore from at any time.

The data moves directly between the two storages. Nothing is downloaded to your server or device on the way, so a plan can mirror a large bucket without needing local disk space for it.

The usual reason to create one is protection against losing a provider. If your working data lives in an Amazon S3 bucket, a storage sync plan keeps an identical copy in Backblaze B2, Google Cloud Storage, a NAS reached over SFTP, or a local disk. If the original bucket is deleted by mistake, the account is suspended, the provider has an outage, or the data is corrupted, the second copy is already up to date and you can restore from it.

Common reasons to use one:

  • keeping production object storage duplicated at a second provider for disaster recovery
  • pulling cloud data down to a local disk or NAS so at least one copy is under your own control
  • copying a bucket into cheaper storage for a low-cost extra copy
  • keeping a new provider current while you migrate away from an old one
  • protecting a shared cloud drive that several people can change or delete

Storage Sync is a Pluton PRO feature.

How a Storage Sync Plan Works​

When the schedule fires, Pluton compares the source path against the destination and transfers only the difference.

  1. Pluton lists the source path and the destination path and compares them.
  2. New and changed objects are transferred to the destination.
  3. Objects that no longer exist at the source are removed from the destination, or moved into the revision area if you enabled file revisions.
  4. Unchanged objects are skipped, so later runs are much smaller than the first one.
  5. If you added extra destinations, each one is synced from the same source in the same way.
  6. Pluton records what changed, saves the result in the plan history, and sends a notification if the run failed.

By default Pluton decides whether an object changed by comparing its size and modification time. You can switch to a checksum comparison for stricter matching, or to a size-only comparison for speed.

What a Storage Sync Plan Does​

Keeps a Browsable Copy​

  • The destination holds ordinary files and folders, not an archive format
  • You can browse the copy from the plan page, or open it directly in the provider's own console
  • Anything in the copy can be downloaded or restored without unpacking a snapshot

Runs on Your Schedule​

  • Choose an interval that matches how often the source actually changes
  • You can also run a sync at any time with Sync Now
  • Pausing a plan stops the schedule and leaves the copied data untouched

Copies to Several Destinations​

  • Enable replication to add up to five more destinations
  • Each destination receives its own copy from the same source
  • Replications can run one after another, or at the same time
  • This gives you the second and third copies of a 3-2-1 strategy in one plan

Skips What You Do Not Want​

  • Exclude patterns keep caches, logs, temporary objects, and generated output out of the copy
  • Patterns are relative to the source path
  • Pluton's own metadata folder is always excluded, so it is never copied back into the source

Keeps Previous Versions​

  • With file revisions enabled, an object that is about to be replaced or deleted is kept aside first
  • This gives you a rollback window for changes that were already synced to the copy
  • Retention is by age, and cleanup runs in the background
  • See Sync File Revisions for how to size and tune this

Shows What Happened​

  • Live progress shows transferred bytes, speed, active transfers, checks, errors, and estimated time
  • A running sync can be cancelled from the plan page
  • Every run is recorded with the files it added, changed, or removed
  • Failure notifications name the plan and the source storage

Verifies the Copy​

  • Check Integrity compares the source against each destination on demand
  • The result lists matches, missing objects, and differences
  • See Sync Recovery and Integrity Checks for how to read it

Restores Back to the Source​

  • Files can be restored from the live copy, or from a past run if revision data still exists
  • Restores are written back into the source storage at their original path
  • Individual files and whole folders can also be previewed and downloaded

Typical Use Cases​

Second Provider for Disaster Recovery​

Keep a production S3 bucket duplicated in Backblaze B2, Wasabi, or Google Cloud Storage. If the primary bucket is emptied, corrupted, or unreachable, the duplicate is current and restorable.

Cloud Data Brought Back On-Premise​

Mirror a cloud bucket or a shared cloud drive to a local disk, a NAS, or an SFTP server, so at least one copy sits on hardware you control.

Protection Against Accidental Deletion​

Mirror a shared cloud drive that many people can write to, with file revisions enabled, so a deleted or overwritten file can be recovered for as long as your retention allows.

Provider Migration​

Keep a new provider current on a schedule while you move workloads across, then cut over once the copy is verified.

Cheap Secondary Copy​

Copy an active, expensive bucket into archival or low-cost storage for a duplicate that costs little to keep.

Fan-Out Redundancy​

Use replication to keep one source storage duplicated at several providers at the same time, without creating a plan for each one.

Things to Know​

  • A storage sync plan keeps a current copy, not a history of every past state. For point-in-time recovery, use an incremental backup plan as well.
  • The copy follows the source in one direction only. Changes made at the destination are overwritten or removed by the next run.
  • Each plan syncs one source path. For unrelated roots, create one plan per root.
  • The source storage and the destination storage must be different, and the source cannot also be a replication destination.
  • The source storage is fixed once the plan is created. The source path, exclude patterns, and schedule can be changed later.
  • A storage that a plan uses as its source cannot be deleted until that plan is removed.
  • Syncs run on the main Pluton server. No agent is involved, even when the storages are remote.
  • Every run lists both sides. Frequent schedules on large buckets increase provider request and egress costs.

Storage Sync and Sync Backup Plans​

Both plan types keep a one-way, scheduled, browsable copy, and both support exclude patterns, file revisions, integrity checks, and restore. The difference is where the data comes from.

  • Use a storage sync plan when the data already lives in a storage, such as an S3 bucket or a cloud drive.
  • Use a sync backup plan when the data lives on a device, such as the Pluton server or a machine running Pluton Agent.

Because the source is a storage rather than a device, a storage sync plan uses a single source path and is not listed under any device.

Best Practices​

  1. Verify both storages are reachable before you rely on the schedule.
  2. Start with a small source path to confirm the plan behaves as you expect.
  3. Keep one source root per plan for clearer history and simpler troubleshooting.
  4. Use exclude patterns to keep caches, logs, and generated output out of the copy.
  5. Match the interval to how often the source really changes, and to what the provider charges.
  6. Enable file revisions where accidental deletion is a realistic risk, and keep retention short on busy sources.
  7. Run an integrity check after large changes or after a provider incident.
  8. Pair critical data with an incremental backup plan when you also need historical recovery.

Next Steps​