If you’ve been using N2W for a while, you’re probably familiar with our S3 Bucket Sync feature. It’s a reliable way to replicate static data by copying objects from a source bucket to a destination bucket so you always have a second copy somewhere else. It’s essentially a smart copy-paste between two locations and it’s still fully supported, still in the UI, and still great for what it was designed to do.
S3 Bucket Sync vs. PIT Backup: What’s the Difference?
Point-in-time backup and syncing are two different things. With S3 Bucket Sync, both buckets always reflect the same current state. That’s useful for redundancy, but if a file gets corrupted or accidentally deleted, you aren’t able to recover from a previous version of your bucket.
N2W has introduced S3 Bucket Backup, which takes a snapshot of your bucket at a specific point in time. That means if you took a backup at 5am and something went wrong at noon, you can restore exactly to what your bucket looked like at 5am, along with files, object tags, and access control lists (ACLs).
An additional bonus is N2W’s options for seamless Cross-Region & Cross-Account for your S3 buckets.
Both features coexist in the N2W interface, and you can use either or both depending on your needs.
Getting Started with Point-In-Time S3 Bucket Backup: The Prerequisites
There are a few things you’ll need to have in place on the AWS side before S3 Bucket Backup will work:
- S3 versioning must be enabled on the bucket you want to back up. AWS Backup relies on versioning to capture point-in-time snapshots.
- Opt in to S3 in AWS Backup. Head to the AWS Backup console and explicitly enable the S3 service. This needs to be done per region — if you skip this step, you’ll see an error when the backup runs.
- For the full list of AWS prerequisites, see AWS’s official dev guide for S3 backups.
Setting It Up in N2W
Once your AWS environment is ready, adding S3 backup to a policy is straightforward. Navigate to the Backup Targets tab when creating or editing a policy, and add your S3 bucket as a target.
When you click Configure, you’ll be asked to choose:
- Backup Vault — the AWS Backup vault where your snapshots will be stored.
- IAM Role — make sure the role has the necessary permissions for S3 backup and restore operations. AWS provides specific guidance on the required role policies, and N2W surfaces this during configuration.
- Expiration — this is where you decide how long to keep your backups. Choose between expiration by policy or by a specific retention window. If you’re taking daily backups and never cleaning them up, storage costs will climb. Setting a retention policy ensures older snapshots are automatically deleted, keeping things tidy and cost-effective.
If Disaster Recovery is enabled in your account, you’ll also configure the Backup Vault and IAM Role for the DR copy.
What Gets Backed Up?
When N2W backs up your S3 bucket, it captures more than just the objects themselves. Your object tags and access control lists (ACLs) are included in the backup, so when you restore, your permissions and metadata come back with it, not just the raw data.
Why Not Just Use AWS Backup Directly?
AWS Backup is the engine under the hood here, but configuring and managing it natively means working in yet another console, building policies in isolation, and not having bullet-proof resiliency due to limited RTO and lack of cross-region and cross-account backup.
If you’re already managing EC2 instances, RDS databases, EFS volumes, and more through N2W, adding S3 buckets as backup targets inside the same policy is a significant operational advantage. With N2W, your S3 buckets sit alongside all your other AWS resources under a single pane of glass. When something goes wrong, recovery is immediate and handled from the same place you manage everything else, whether you need to recover from your native backup account, or from another region or disaster recovery account.
This is S3 protection that actually fits into how your team already works. Be sure to try S3 Bucket Backup today.