TrueCrypt / SSH (SFTP) / Cannot access the file

[e-backup]

Dear Forum !

I m using Syncovery since many years and it's the best backup tool.
I would like to backup a truecrypt archive on a remote server via SSH/SFTP.

I m using following options :
– Sync Operation mode: Profile with Standard Copying mode
– Special: Partial File Updating

Backup can't work while the archive is mounted with truecrypt. A got following message:
"Errors with 1 File(s). Last msg: The process cannot access the file because it is being used by another process"

Is there a way to do this ?

Many thanks in advance !

Cheers,
M. Backup.

[e-backup]

Good morning everyone !

Point A:
------------
I don't find yet a solution with a mounted TrueCrypt archive --> On hold

Point B:
-------------
I will try to be brief and concise.

I ran some test with following instructions:
https://www.syncovery.com/block-level-copying/

This method sound good with large TC archive (client) and SSH/SFTP server.
Furthermore, it save bandwidth and time !

For the test, I used:
- A 100 Mb/s up/down speed between client and server .
- 2 GB TC archive (unmouted)
- SSH server with DEBUG log level

The test:
- Syncovery run the first time a full upload (2 GB)
- Then, I modified a 30 MB file inside the archive

What happened:
- Syncovery use SFTP with following behaviour:
- open the archive
- scan the archive
- write necessary changes in the archive
- close the archive
- Regarding the bandwidth it's OK. Syncovery upload only the part of the file which is modified.
- Regarding the time it's not OK. Syncovery browse the whole archive and it took 46 sec (2 GB).

Comments:
It's about 23 sec / GB:
- With 100 GB archive = 38 min
- With 500 GB archive = 191 min

Even if you change one bit in the archive, you'll have to wait the whole scan.

Question:
Is there a way to avoid this ?

Many thanks for your respons (A and B) !
Cheers,
M. Backup.

[superflexible]

Hello,
if the TrueCrypt archive is on a local hard drive, Syncovery can copy it using Volume Shadowing.

Concerning the time this takes, that's how it is. It cannot be made faster. Syncovery has to scan the whole file locally and calculate MD5 checksums for all the blocks and compare them to the ones saved in its database. That takes some time.