S3 Backup You Can Restore With Any Tool
Most S3 backup tools optimize the write path with compression, deduplication, and packed repositories; Godwit Sync optimizes the restore. Whether the source is a server directory, a NAS share, or another bucket, every file lands as a plain S3 object at its original key, readable by any S3 client, with no proprietary repository to unpack. Backups are incremental after the first run, checksum-verified, and written into your S3 Versioning and Object Lock buckets, so each restore point inherits the bucket's retention.
Backup guarantees
S3 backup as plain objects, not chunked repos
Godwit Sync applies these five guarantees to every run, from a single server directory to a full bucket. They matter most at restore time.
Plain S3 objects
Restore with any S3 tool, no proprietary repository.
s3://backups/srv-data/
- etc/nginx.confv3
- docs/report.pdfv8
- db/snapshot.sqllocked
Incremental
Only changed files after the first run.
Checksum-verified
Checksums recorded on upload, re-read and compared on verify.
Object Lock aware
Each version written to an Object Lock bucket inherits its retention.
Resume-safe
Interrupted runs resume instead of restarting.
S3 backup without a proprietary repository: vs restic and rclone
The table below compares how Godwit Sync, restic, and rclone store data, restore it, and hold up to Object Lock.
| Capability | Godwit Sync | restic | rclone |
|---|---|---|---|
| Storage format | Native S3 objects at their original keys | Content-addressed repository of encrypted, packed blobs | Native files and objects at their original paths |
| Restore without the tool | Yes; any S3-compatible client reads the objects directly | No; files exist only as blobs, so restic and the repository password are required to reconstruct them | Yes; files are stored verbatim |
| Versioning | Uses destination bucket S3 versioning when enabled; keeps no separate snapshot history | Snapshot-based; every run is a point-in-time snapshot with full history | None built in; relies on backend versioning or --backup-dir |
| Object Lock / WORM support | Preserved on replication if Object Lock is configured at the destination bucket; not managed by Godwit Sync | Incompatible. restic prune and repack operations attempt to delete and overwrite objects, which Object Lock blocks. | Not enforced by rclone; retention is governed by the destination bucket |
| Change detection / deduplication | Object-level change detection by size, mtime, and ETag. Single-file restore is one S3 GET, with no index traversal, no pack extraction, and no egress on adjacent data. | Content-defined chunking with cross-snapshot deduplication. Single-file restore requires reading the snapshot index and one or more 128 MB pack files containing chunks from multiple files. | Object-level change detection by size and modtime (checksum optional). No deduplication. |
| Integrity verification | Per-object ETag comparison on transfer; MD5 recorded in a signed baseline ledger for later drift verification | SHA-256 over every chunk; restic check re-verifies repository integrity | Optional post-transfer checksum comparison with --checksum (size and modtime by default) |
| Vendor lock-in | None for stored data; objects stay standard S3 and remain accessible without Godwit installed | High; data cannot be restored without restic and the repository password | None for stored data; files stay standard objects |
S3 backups stay readable, incremental, and verifiable
Godwit Sync uploads a full first copy, tracks the last confirmed run, and sends only changed files after that. The destination stays as ordinary S3 objects the whole time.
Example S3 backup commands
Nightly backup of a server directory to S3
$ godwit sync \
--incremental --run-id nightly-backup \
--source /srv/data \
--destination s3://backups/srv-data \
--destination-endpoint s3.amazonaws.comThe first run uploads everything. Later runs upload only changed files from the confirmed baseline.
Versioned, immutable bucket-to-bucket backup
$ godwit sync \
--source s3://app-data \
--destination s3://offsite-backup \
--destination-endpoint s3.us-west-1.wasabisys.com \
--version-mode all --object-lockA versioned bucket with Object Lock turns each change into an immutable restore point.
Verify the backup is intact
$ godwit plan verify \
--run-id nightly-backup \
--destination s3://backups/srv-data \
--destination-endpoint s3.amazonaws.comRe-read every uploaded object and compare it with its .md5 sidecar.
Restore a backup to a local directory
$ godwit sync \
--source s3://backups/srv-data \
--source-endpoint s3.amazonaws.com \
--destination /srv/restoreRead the backed-up objects back to disk. On a versioned destination, each change is its own restore point, so you can pull an earlier one with any S3 client too.
S3 backup FAQ
How do I make backups immutable against ransomware?
Immutability comes from the destination bucket, not from Godwit Sync. Enable S3 Object Lock and a default retention period on the destination bucket first; then every object Godwit Sync uploads, including each new version, inherits that retention, so restore points cannot be deleted or overwritten before their retain-until date. For bucket-to-bucket backups, add --object-lock and Godwit Sync also replicates the source's existing GOVERNANCE or COMPLIANCE retention and legal hold per version.
Can I back up many buckets or several clients?
Yes. Each backup is an independent job with its own reusable run ID, source, and destination, so you can script one job per directory, bucket, or client into cron, systemd, or your own scheduler. Jobs are resume-safe and incremental, and each destination stays as plain, separately restorable S3 objects. Centralized recurring install with godwit schedule and run-summary webhooks are on the roadmap.
Can I back up a NAS or home server offsite to S3?
Yes. Point Godwit Sync at any local or mounted directory, including a NAS share or a home server's data folder, and back it up to any S3-compatible storage such as Backblaze B2, Wasabi, or MinIO. The first run uploads everything; later runs send only changed files. Wrap it in cron, systemd, or Task Scheduler for unattended offsite backups, and restore any file later with any S3 client.
How is this different from restic, Kopia, or Backrest?
restic, Kopia, Borg, and Backrest store data in a proprietary repository. Godwit Sync writes each file as a normal S3 object under normal keys, so you can list, download, and restore with rclone, the AWS CLI, or any S3 tool. The trade-off is that Godwit Sync does not deduplicate across unrelated files.
Can I restore a single file or an older version?
Yes. Each file is a plain object, so you can restore one file with any S3 tool. On a versioned destination bucket, each change is a separate S3 object version, so you can pull the version from before a deletion, overwrite, or ransomware event.
Are the backups incremental?
Yes, after the first full run. Godwit Sync compares the source against the last confirmed-completed baseline and uploads only changed files. Change detection uses content metadata such as size plus ETag, or size plus mtime when needed.
How do I know a backup actually worked?
Godwit Sync writes an .md5 sidecar for every uploaded object. Run godwit plan verify to re-read the backup and compare checksums. The status endpoint and exit code show whether the run finished cleanly, so a half-finished run does not pass as success.
What can I back up, and where to?
Back up a local server directory to S3, or one bucket to another, between any S3-compatible storage: AWS S3, MinIO, RustFS, Ceph, Cloudflare R2, Backblaze B2, Wasabi, DigitalOcean Spaces, or self-hosted object storage.
What does it cost?
The free plan covers 50 GB per run with no expiration. Registration unlocks unlimited capacity for 30 days. Paid plans are flat licenses based on per-run capacity. Godwit Sync does not charge per-GB or egress fees, but your storage provider still can. Because licensing is by per-run capacity rather than per-GB or egress, cost scales with the size of each backup job, not the number of clients or total bytes stored.
Planned next for the fuller backup workflow
Start with an S3 backup you can verify and restore.
50 GB per-run free tier, no expiration. Unlimited for 30 days after registration.