SFTP Mirroring w/ Version + Block-Level

[tobias]

Hi,
OK, so does the command line look correct to you?

cp -p "/volume1/AppData/CherryTree.ctb" "/volume1/AppData/$VERSION$/CherryTree.d20220907-u153156.ctb"

Maybe you can try it in a shell?

Oops, I think the $ is poisonous for command lines.

I think it has to be escaped even if the path is within double quotes.

Can you try without $ in the versions folder, or wait for the next update. I can actually release another one today.

[tobias]

Hello,
you can try build 16 now. It will handle dollar signs in the versioning path correctly.

[DrkMstr310]

Hi,

Thanks for the quick build.

Unfortunately, I gave it a try & the results are the same (except that I can now see in the first line of the log that the $ are escaped):

Code: Select all

Executing SSH shell command: cp -p /volume1/AppData/CherryTree.ctb /volume1/AppData/\$VERSION\$/CherryTree.d20220908-u004645.ctb

If I manually remove the CherryTree.d20220908-u004645.ctb versioned file, then login to a terminal & run that "cp" command, it does indeed work: I can see it copy the file to CherryTree.d20220908-u004645.ctb.

However, in doing so, I think I realize 2 blocking issues with this approach:

1) Since a little while ago, it seems that Synology only allows ssh terminal access to admin, aka root users: https://community.synology.com/enu/forum/1/post/125859. This means giving the sftp user full administrative privileges. And:
2) Per security best practices, the ssh shell port is not exposed to the open internet (only within the LAN); so if this copy operation requires like the same thing as a "standard terminal connection," it means backups could not be run from anywhere outside of the LAN (without exposing full root access to the world). Somehow I had imagined that the cp command travels through the "same" sort of connection as sftp, but not a true full administrative shell.

Thus, it seems like remote service is really the only safe way to do this.

(As a side note, just out of curiosity, I did try it with the sftp user added to the administrators group, and didn't seem to get it working even on my lan, so there does still seem to be even yet an additional issue. However, even if it did work, the real goal of "block level" is for fast remote/internet backups - so it seems this limitation makes Remote Service really the only solution - I think?)

[tobias]

Hello,
yes it assumes that the SFTP and SSH port are the same number.

OK, I will add the necessary feature to the remote service. That way, a lot more customers will benefit from it, i.e. those that copy to UNC paths over LAN or VPN.

[DrkMstr310]

Excellent - yeah, that was my thought. That way, there's pretty much no limitations or requirements: no special server features, no remote admin access required, no port limitations, etc. Just works the same for everyone

[tobias]

Syncovery 10.dev.17 can now combine versioning with block level copying, using the Syncovery Remote Service v10.00 to make a copy of the last file version. There is a new checkmark on the Special tab sheet: X Use Remote Service to Copy Files for Block Level Copying + Versioning.

The new Syncovery Remote Service v10.00 is available for Windows, as well as Synology and some Linux distribution packages. It is currently available for 32-bit and 64-bit Intel/AMD CPUs as well as 64-bit ARM (Aarch64). The 32-bit ARM version is not available yet.

The Synology Remote Service can be downloaded from the following page. There are separate packages for DSM 6 and 7.
https://www.syncovery.com/syncovery9synology/

For DSM7, the SyncoveryRS user must be given permissions to the folders. Please see the following instructional page, but choose the SyncoveryRS user rather than Syncovery. This user exists is automatically when the Syncovery Remote Service is installed.
https://www.syncovery.com/syncovery-wit ... ogy-dms-7/

Finally, the Remote Service must be configured via its configuration page on port 8949. You need to give it the local folder that corresponds to the base folder that Syncovery syncs with. For example:

/volume1/AppData

If there are issues, the log file will contain some details. But if the Remote Service for some reason cannot fulfill its job, the log file will only mention that no progress was detected within 60 seconds. In that case, check the Remote Service configuration and permissions.

[DrkMstr310]

Looks like it works!! Great job!

[tobias]

Thanks!