Migration of Recordings from FTP to AWS S3 and Backup Redundancy in 3CX v20 U7

[FELIPE.HOFFENS@BLACKLAYER]

Dear 3CX Team,


I hope you’re doing well.


We are currently running an on-premise 3CX v20 Update 7 installation with automatic recording archiving to a remote FTP server. The system is functioning properly — 3CX transfers the recordings, updates the “archived” flag in the database, and when downloading from the Management Console, it retrieves them dynamically from the FTP path.


We’re now planning to migrate this setup to the new AWS S3 Elastic Archiving module and would like to confirm a few technical details to ensure referential integrity and resilience.

1. Recording index consistency and database integrity​

We understand that 3CX maintains references to archived recordings in its internal database (CallRecordings table), where each record includes the storage path (ftp://...) along with call metadata.
In this context:

• Is there any automatic path remapping mechanism when switching the archive backend from FTP to S3?
• If we perform a mass migration (e.g., using rclone, aws cli s3 sync, or equivalent utilities), will the internal database automatically update its file pointers to s3://..., or will they remain static with the original FTP paths?
• If the references remain static, does 3CX provide any reindexing or rescan process (similar to a “sync job”) to rebuild associations between existing call records and the new objects in the bucket?

The goal is to avoid orphaned download links or inaccessible recordings in the Management Console after switching storage backends.

2. Resynchronization and archiving logic​

When the storage target changes (for instance, from FTP to S3), does 3CX perform any internal resynchronization of existing archive records, or does it simply begin archiving new recordings to the new target while leaving existing entries untouched?


If the latter, is there any officially supported controlled migration procedure to ensure consistency between system metadata (archived flag, timestamps, hashes/checksums) and the migrated files in the new backend?


Additionally, could you confirm whether the archiving engine uses absolute paths stored in the database, or if it dynamically builds the retrieval URL based on the currently active configuration?
This distinction has a direct impact on how the migration strategy should be designed.

3. Configuration backup redundancy and resilience​

With the adoption of the new S3 archiving feature, it appears that both large data volumes (recordings, logs) and configuration backups are centralized in the same destination.

We’d like to confirm whether it’s possible to:

• Define an alternate or secondary destination (e.g., Google Drive, SFTP, or another cloud endpoint) for configuration-only backups, and
• Implement a cross-redundancy policy to minimize the risk of data unavailability in case of S3 bucket outages or administrative events such as temporary AWS account suspension.

From an architectural perspective, we fully support offloading large datasets from the PBX core — that’s an excellent design decision. However, resilience requires separation of data and configuration storage to ensure operational continuity.



Thank you very much for your time and for clarifying these technical aspects.

Your guidance will help us design a safe migration strategy aligned with 3CX best practices for data integrity and redundancy.


Kind regards,

Felipe

 

[pivotal]

Felipe,

I see no one answered your question. I have a similar situation. We need to move our storage from an SFTP server to a different FTP server. All of your questions are exactly what I was wondering.

Did you move forward with this migration? What answers did you find to these questions?

Does anyone else have answers to these questions? We are running version 20.0.8.1121 with our storage location configured as an SFTP server. It is archiving Chat Files, Faxes, Recordings and Voicemails to that location. Ideally, we would like to change the location to a new FTP server and move all of the existing archives from the old location to the new location.

Thanks,
Bob