Note:
- This tutorial requires access to Oracle Cloud. To sign up for a free account, see Get started with Oracle Cloud Infrastructure Free Tier.
- It uses example values for Oracle Cloud Infrastructure credentials, tenancy, and compartments. When completing your lab, substitute these values with ones specific to your cloud environment.
Perform Cross-Region Bidirectional Synchronization in Oracle Cloud Infrastructure using Syncthing
Introduction
Cross-region object storage synchronization is essential for various cloud workloads, including data backup, disaster recovery, and multi-region access. While Oracle Cloud Infrastructure (OCI) provides replication capabilities for OCI Object Storage, it does not offer a native bidirectional synchronization solution. This limitation means users must rely on custom implementations to sync files across regions.
Syncthing, an open-source, decentralized file synchronization tool, provides a continuous, bidirectional sync alternatively that operates in real-time. Unlike OCI Functions, which rely on an event driven model for object replication, Syncthing synchronizes entire file structures efficiently between virtual machines (VMs) while supporting local and OCI Object Storage mounted directories.
In this tutorial, we will deploy Syncthing on OCI Compute instances across two regions using an OCI Resource Manager stack, enabling automatic, bidirectional synchronization between local VM storage and OCI Object Storage mounted directories.
Considerations
When you mount Syncthing with OCI Object Storage using s3fs:
-
s3fs (OCI Object Storage) write performance can be a bottleneck: Writing directly to OCI Object Storage using s3fs is slower compared to local disk.
-
Syncing large files can be slow: Writing and reading large files directly from OCI Object Storage can take minutes instead of seconds.
-
Block-level sync advantage lost: Since OCI Object Storage requires full-object writes, Syncthing’s block-level sync efficiency is diminished.
-
Best practice: Sync locally first, then move files to OCI Object Storage.
When is Syncthing a good idea?
-
Best for real-time synchronization, especially for high-frequency small file changes across regions.
-
Ideal for bidirectional sync, unlike OCI Functions, which require additional logic for two-way updates.
-
Great for hybrid cloud or on-premises to OCI sync, where direct OCI Object Storage integration is not feasible.
-
Best when syncing local VM storage: Avoid using s3fs mounted buckets for direct sync.
-
Not ideal for large batch file transfers: OCI Functions handle these more efficiently with per object processing.
Objectives
-
Deploy an OCI Resource Manager stack in two regions to automatically provision two OCI Compute instances with Syncthing pre-installed.
-
Configure Syncthing on both VMs to enable real-time, decentralized synchronization of local storage and OCI Object Storage mounted directories across multiple regions.
Prerequisites
-
Access to an OCI tenancy with two enabled regions for cross-region synchronization.
-
Permissions to create and manage OCI Compute instances, OCI Object Storage buckets, and networking resources.
-
An existing VCN with a public subnet in each region for VM deployment.
-
Existing OCI Object Storage buckets in both regions, which will be used for synchronization.
-
A customer secret key for S3 File System (s3fs) to mount OCI Object Storage buckets on the VMs.
Task 1: Prepare the Necessary Information for the VM Deployment
-
Download the OCI Resource Manager stack. This stack automates the deployment of a VM running Oracle Linux 8 on a VM.Standard.E5.Flex shape. It installs Syncthing using CloudInit, mounts an existing OCI bucket, and configures access using s3fs. The VM is provisioned with SSH access, a public IP, and tagged for easy identification. For more information, see OCI Resource Manager stack.
-
Create a VCN with a public subnet in both target regions.
The stack will be deployed in both locations to provision a VM with Syncthing for bidirectional cross-region storage synchronization. Once deployed, Syncthing can be accessed in the browser using the VM’s public IP.
-
Ensure an OCI Object Storage bucket exists in each region where the tests will be performed. The visibility of the bucket can be Private.
-
Create a customer secret key for s3fs mount. The customer secret key will be used for accessing the OCI Object Storage.
-
Log in to the OCI Console, navigate to Profile, click your username and Customer Secret Keys.
-
Click Generate secret key and enter a name, such as
s3fs-access
. -
Make sure to copy the generated key as we will use it later in Task 2.
-
Click Access key and copy the value as we will use it later in Task 2.
-
Copy Namespace from the Bucket details page which we will use later in Task 2.
-
Task 2: Apply the Stack
-
Log in to the OCI Console, navigate to Developer Services, Resource Manager and click Stacks.
-
Create the Terraform OCI Resource Manager stack. For more information, see Creating a Stack from a Zip File.
-
Click Create stack.
-
Select
.zip
file and add the stack. -
Enter Tag key.
-
Click Next.
-
-
In the Configure variables page, enter the following information.
- Compartment: Enter the compartment.
- VCN and Subnet: Select an existing VCN and a public subnet.
- Modify the vm display name if you wish.
- Public SSH Key: Enter the public SSH key for the VM.
- Availability Domain: Select availability domain.
- Customer secret key OCID and Customer Secret Access Key: Enter the customer secret key OCID and customer secret access key created in Task 1.
- Bucket Name: Enter the bucket name.
- Object Storage Namespace: Select object storage namespace.
-
Click Next and review the information. If everything is ok, then select Run Apply and click Create.
When the apply job successfully completes, it should return the public and private IPs of the newly created VM.
-
Repeat the steps in a secondary region to create the second VM there.
-
Confirm that the OCI Object Storage buckets are mounted to
/home/opc/logging
at the VM level, by connecting over SSH using the following commands.mount | grep s3fs
If the bucket is successfully mounted, you should see the output similar to:
This confirms that s3fs has mounted the bucket to
/home/opc/logging
on any of the VMs.
Task 3: Configure Syncthing
Once both VMs are deployed in the two regions, configure Syncthing on each VM by following the steps below to synchronize storage between them.
-
Copy the public IP of the VM in the first region and use it in the browser to access the Syncthing interface. Enter the following URL.
http://<vm1-public-ip>:8384
-
After you access the interface, you will see the Syncthing interface which will be similar to the following image. Folders and Remote Devices are the areas you will configure for synchronization in the next step.
Note: You can set a username and password in the Settings under the GUI section to remove the warnings.
-
In the Folders section, click Add Folder to create or include a local VM folder in the Syncthing administration interface.
-
Enter the following information to configure a local folder and click Save.
- Folder Label: A user-friendly name to identify the folder. For example,
local_VM1
. - Folder Path: The directory path of the local folder. For example,
~/local_VM1
.
You can check in the VM terminal that the new folder
local_VM1
created. - Folder Label: A user-friendly name to identify the folder. For example,
-
Repeat steps 1 to 4 in the VM from the secondary region, and add
local_VM2
folder in the VM2 Syncthing interface. -
Configure the cross-region Syncthing connection between the two VMs, starting with VM1.
-
In the Remote Devices section of the first Syncthing VM, click Add Remote Device to include a remote folder from the second region.
-
In General, enter the following information.
-
Device ID: This is the ID of the second Syncthing device. On VM2, open the Syncthing interface, navigate to Actions, Show ID, copy the displayed value, and paste it into this field.
-
Device name: Enter a relevant name such as
remote_VM2
.
-
-
In Sharing, select
local_VM1
to be shared with the remote device. -
In Advanced, enter
tcp://<vm2-public-ip>:22000
in Addresses,22000
is the TCP port used for Syncthing data. -
Click Save.
-
-
At this point, on VM1 Syncthing, the local folder
local_VM1
should show up in green Up to Date and the remote deviceremote_VM2
will show Disconnected.In order to complete the connection, perform the same steps on VM2 Syncthing, using the equivalent data collected from VM1 Syncthing, enter Device ID,
tcp://<vm1-public-ip>:22000
as Addresses and Device name such asremote_VM1
.Note: Make sure the port
22000
is open in the security list of the VCNs. -
After the equivalent configurations you should be prompted in each Syncthing interface for accepting the addition of the remote folder. Click Add.
-
You will be prompted to save it locally with specific details, for example, on VM1 you will be prompted to save the incoming
local_VM2
, you can change the name for it on VM1 toremote_VM2
for a clearer display. Also you have the possibility to map it to a local VM1 path. It can be any path; a new folder is created if it does not exist. You can also select~/local_VM1
, meaning that the content of the two folders from the two VMs will be merged in the same location. For our example, enter the path~/remote_VM2
. -
Perform the same step on VM2 relative to the incoming
local_VM1
folder and map it asremote_VM1
. -
Now, the two VMs should be in sync and folders administered by Syncthing; on VM1, the
local_VM1
andremote_VM2
; on VM2, thelocal_VM2
andremote_VM1
.
Task 4: Test Synchronization of Local Storage
To test Syncthing synchronization, log in to each VM using SSH. Inside the opc home directory, you will find two folders.
-
Local folder (
local_VM1
): Stores files on this VM. -
Remote folder (
remote_VM2
): Reflects synchronized files from the second VM.
To verify synchronization, we will add or modify a file in the local folder on one VM and check if the changes appear in the corresponding folder on the remote VM. Additionally, we will monitor the Syncthing interface or logs to confirm successful synchronization between the two OCI regions.
-
SSH into VM1.
ssh opc@<vm1-public-ip>
-
Run the following command to navigate to the local Syncthing shared
local_VM1
folder.cd ~/local_VM1
-
Run the following command to create a test file.
echo "testing sync" > testVM1.txt
-
Open a new terminal and SSH into VM2.
ssh opc@<vm2-public-ip>
-
Run the following command to navigate to the shared folder on VM2.
cd ~/remote_VM1
-
Run the following commands to check if the file appears.
ls -l cat testVM1.txt
-
Perform the same steps on VM2 and check that a file appears on VM1 in
remote_VM2
folder. -
Verify synchronization status in the Syncthing interface. Open
http://<vm1-public-ip>:8384
andhttp://<vm2-public-ip>:8384
in a browser to check logs and sync status.
Task 5: Test Synchronization of OCI Object Storage Bucket Content
The buckets are mounted on the VMs deployed in the /home/opc/logging
directory. In order to test and synchronize files located in the mounted buckets you need to redo the previous steps in order to add the logging
VM directory as a local folder, then share it from the Remote Devices. You will see something similar to this:
-
VM1:
Next, create a file in the logging
directory which will make it appear in the OCI bucket as well as synchronize to VM2 logging
directory if correctly configured, hence in the second bucket from the cross region as well.
Task 6: Perform Some More Tests
There are two points which you can easily further test with the same folder and shared devices as configured previously.
-
Test using New Large Files: This will sync quickly. Create large file locally on the VM in the
local_VM1
/local_VM2
folders, then create thelogging
directory which means s3fs is used for cross-region OCI Object Storage synchronization.-
Create a large file on VM1.
cd local_VM1 dd if=/dev/urandom of=~/local_VM1/testfile1 bs=1M count=500
-
Verify sync on VM2.
ls -lh ~/local_VM2/
Also verify in the VMs Syncthing interface.
-
Repeat for s3fs mounted directory (
logging
).cd ~/logging dd if=/dev/urandom of=~/logging/testfile2 bs=1M count=500
-
Verify sync on VM2 in the
logging
directory, in the Syncthing interface, as well as in the second regions bucket in order to determine how fast the file appears. -
You can then proceed to perform the same tests with a file of a few GB. Also consider uploading a large file directly to first bucket and monitoring how fast it is synchronized to second bucket.
-
-
Test using Modified Large Files: This will also efficiently detect and sync the changes. Modify local files in
local_VM1
/local_VM2
directories and existing files in the OCI Object Storage buckets mounted to the VMs under thelogging
directory.-
Modify an existing file.
echo "New content" >> ~/local_VM1/testfile1
-
Verify the update on VM2.
-
Repeat step 1 and 2 for OCI Object Storage files.
echo "Modified content" >> ~/logging/testfile2
-
Related Links
Acknowledgments
- Author - Adina Nicolescu (Senior Cloud Engineer)
More Learning Resources
Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.
For product documentation, visit Oracle Help Center.
Perform Cross-Region Bidirectional Synchronization in Oracle Cloud Infrastructure using Syncthing
G29460-01
Copyright ©2025, Oracle and/or its affiliates.