How to synchronize Call Recordings to NAS

My company has FreePBX 5.211.65-21 and we just have NAS Sysnology DS218. I would like to install Cloud Station Drive (client software like OneDrive) to synchronize call recordings from FreePBX to our NAS. The Cloud Station Drive supports Windows, Mac, Fedora (rpm) and Ubuntu (deb). Could I setup the Cloud Station Drive on FreePBX 5.211.65-21?

Set up a test system and try it. I’d probably use the Fedora base to start.

https://www.synology.com/en-us/knowledgebase/DSM/tutorial/File_Sharing/How_to_access_files_on_Synology_NAS_within_the_local_network_NFS

1 Like

@jfinstrom TheJames: Do you mean mount a NAS based share on /var/spool/asterisk/monitor? If so what happens during network disruption, will the recording not be recorded during that time?

@cynjut Dave Burgess: I have already installed Gnome on a VM FreePBX because Cloud Station Drive for Linux requires a GUI. But I can not install on FreePBX 5.211.65-21 because 5.211.65-21 is based on CentOS 6 which provides Gnome 2 but Cloud Station Drive for Linux requires Gnome 3.

After that I successfully install Cloud Station Drive for Linux on a VM SNG7-FPBX-64bit-1805-1 throught Gnome interface. Another problem happens: If you don’t log in your account in GUI, the program will not synchronize the files to NAS.

If you are storing your recordings on an NFS share, then that mount point can go stale and block any writes. In /etc/asterisk/asterisk.conf I would add as documented by the authors of asterisk:-

; Cache record() files in another directory until completion
cache_record_files = yes
record_cache_dir =

and place outside of any external file system,

@dicko So if I set record_cache_dir to local storage and during network disruption, recordings will be temporarily written to local storage and then when network is restored, recordings will be moved to an NFS share, will not they?

Yes, that’s one scenario that it is designed to handle.

For similar reasons, another is on a very busy system with transcoding, you might want to use ram as a cache.

1 Like

Typically no calls would occur during a network failure on a VoIP system. You can store locally then rsync or archive. If you mount to /var/spool/asterisk/recordings this becomes a normal folder if the remote mount goes away.

Example: I have a ssh mount to ~/blade15 on failure saves go to ~/blade15 on remount the pointer gets moved back to the mount but the files remain where they are. If I unmount I see them again.

Just to clarify, the device he is using apparently uses NFS and for whatever reason that an NFS mount goes ‘stale’, then it doesn’t “go-away” "it just can’t be writen to. Quick Ref:

https://access.redhat.com/solutions/204423

It is annoyingly difficult to resolve a stale mount. For that reason I myself use rsync/inotify/ssh and that might be another solution for the OP.

I similarly abandoned the use of NFS mounts years ago because of these very reasons. Instead, I use a daily script that converts the wav files to mp3, copy them to a mounted NFS volume, and delete them from the original drive to reclaim the space.

The “second” part of this is adjusting the location so that you can use the “drag and drool” interface to listen to recording from UCP. I don’t bother because the people that are listening to the recordings are NOT the people that recorded them.

@jfinstrom @dicko I just would like to make clear that if user can still make call during that network failure. Network failure means network connection from FreePBX to NFS share is disrupted but FreePBX can still make connection in and out Internet.

@cynjut I already use backup module to schedule backup recordings and then rsync them to other location. But I wonder if I could use real-time synchorization of recordings in FreePBX and my Synologo NAS.

Almost always a network failure between your NFS NAS and your PBX will cause what I spoke about , if you rely on remote mounts. don’t use half-asserd NAS devices, if you do, please cache the recordings before committing them

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.