Greetings!
I've been using (and loving) FreeFileSync for a few years now. Thank you for making the best backup software! I have, however, been learning more about backup software, and have a few questions about FreeFileSync; I was wondering if anyone knew the answers?
Is there any way to achieve encryption in backups? FreeFileSync doesn't support file encryption as far as I know; are there any 3rd-party solutions anyone's used successfully? Or could encryption of backups eventually be implemented?
Does FreeFileSync support delta copy (e.g. like rsync or GoodSync)? Or are there any plans to eventually implement it? Or is there a reason full-file-copy is preferred to delta (e.g. risk of data corruption or something)?
Is there any way to still get the Donation Edition for v10.11 (the last version to support WinXP/WinVista)?
Many thanks!
3 questions: encryption, delta-copy, legacy Donation Edition v10.11?
-
- Posts: 27
- Joined: 26 Nov 2017
-
- Posts: 27
- Joined: 26 Nov 2017
Seems someone else had the same question about v10.11: viewtopic.php?t=7321
-
- Posts: 2272
- Joined: 22 Aug 2012
FFS does (at least presently) not support encryption.
In the past, I have succesfully used FFS in combination with a previous version of BoxCryptor, now referred to as BoxCryptor Classic and still available for up to Win10. BoxCryptor creates a (local) virtual drive with encryption at file-level. As FFS (as you concluded yourself) also does file-level syncing, the two are a good match. The present version of BoxCryptor is much more focussed on syncing to the cloud, but may (also)still provide the (local) virtual drive feature with (file-level) encypted content.
There may however be other encryption tools that work equally well with FFS.
My guess why FFS uses file-level syncing and not delta-syncing: file-level syncing is straight forward, allows simple/direct versioning. But most importantly: after having run the sync, it does not require the tool (or any other tool) to "reconstruct" the latest (or any previous) version of the file from an initial version and all (or part of the) combined deltas.
For me, that is one of the prime reasons for using FFS.
Note, that if you apply encryption (built into your syncing-tool or via an external tool), you obviously always need a tool for decrypting your files, which may cause all sorts of legacy related issues.
In the past, I have succesfully used FFS in combination with a previous version of BoxCryptor, now referred to as BoxCryptor Classic and still available for up to Win10. BoxCryptor creates a (local) virtual drive with encryption at file-level. As FFS (as you concluded yourself) also does file-level syncing, the two are a good match. The present version of BoxCryptor is much more focussed on syncing to the cloud, but may (also)still provide the (local) virtual drive feature with (file-level) encypted content.
There may however be other encryption tools that work equally well with FFS.
My guess why FFS uses file-level syncing and not delta-syncing: file-level syncing is straight forward, allows simple/direct versioning. But most importantly: after having run the sync, it does not require the tool (or any other tool) to "reconstruct" the latest (or any previous) version of the file from an initial version and all (or part of the) combined deltas.
For me, that is one of the prime reasons for using FFS.
Note, that if you apply encryption (built into your syncing-tool or via an external tool), you obviously always need a tool for decrypting your files, which may cause all sorts of legacy related issues.
-
- Posts: 27
- Joined: 26 Nov 2017
Thank you for the information! Certainly is scary to think of my files being reconstructed!
-
- Posts: 55
- Joined: 15 Feb 2018
Hello,
Adding my experience here --
I have created encrypted volumes using VeraCrypt -- https://www.veracrypt.fr/en/Home.html
It works very well. VeraCrypt is a spinoff from the TrueCrypt project that was relenquished by its original developers.
One nice aspect of VeraCrypt is that it runs on Windows, Linux, and MacOS/X.
The whole volume is encrypted and requires a password to mount the volume. Once you provide the volume password and mount it, the entire volume and all files within it are accessible to the system as a regular volume. I believe that the filesystem's administrative access rights prevail, so you don't lose that level of control. When you dismount the volume, only someone with VeraCrypt drivers and your password can mount it. A.K.A. theft protection.
It supports either a Virtual volume mounted on one big contiguous file within your filesystem, or it can take over a whole existing unallocated disk volume associated with a drive letter. Either way, it produces a NEW drive letter which is your encrypted volume. It's easy to use but requires a little bit of learning and practice to make it part of your general routine.
Volumes have to be mounted first, outside the FFS program (you can't manage the filesystems from within FFS). Also, I recommend unmounting VeraCrypt volumes manually after performing backups. VeraCrypt provides a handy console for unmounting and mounting volumes.
I experienced no performance degradation when backing up! (surprising) It took about 5 hours to back up 910 GB to either VeraCrypt or Non-VeraCrypt volumes (using the same interface to the same disk drive.) I assume this was because I have an Intel CPU with AES extensions, and all the CPU overhead fit neatly within the wait times for disk I/O. Results might differ if your CPU doesn't support the encryption parameters that you choose, or if you're writing to SSDs that are much faster, or if you don't have a lot of memory, etc.
All my external backup drives will soon be VeraCrypted.
-JDB
Adding my experience here --
I have created encrypted volumes using VeraCrypt -- https://www.veracrypt.fr/en/Home.html
It works very well. VeraCrypt is a spinoff from the TrueCrypt project that was relenquished by its original developers.
One nice aspect of VeraCrypt is that it runs on Windows, Linux, and MacOS/X.
The whole volume is encrypted and requires a password to mount the volume. Once you provide the volume password and mount it, the entire volume and all files within it are accessible to the system as a regular volume. I believe that the filesystem's administrative access rights prevail, so you don't lose that level of control. When you dismount the volume, only someone with VeraCrypt drivers and your password can mount it. A.K.A. theft protection.
It supports either a Virtual volume mounted on one big contiguous file within your filesystem, or it can take over a whole existing unallocated disk volume associated with a drive letter. Either way, it produces a NEW drive letter which is your encrypted volume. It's easy to use but requires a little bit of learning and practice to make it part of your general routine.
Volumes have to be mounted first, outside the FFS program (you can't manage the filesystems from within FFS). Also, I recommend unmounting VeraCrypt volumes manually after performing backups. VeraCrypt provides a handy console for unmounting and mounting volumes.
I experienced no performance degradation when backing up! (surprising) It took about 5 hours to back up 910 GB to either VeraCrypt or Non-VeraCrypt volumes (using the same interface to the same disk drive.) I assume this was because I have an Intel CPU with AES extensions, and all the CPU overhead fit neatly within the wait times for disk I/O. Results might differ if your CPU doesn't support the encryption parameters that you choose, or if you're writing to SSDs that are much faster, or if you don't have a lot of memory, etc.
All my external backup drives will soon be VeraCrypted.
-JDB
-
- Posts: 27
- Joined: 26 Nov 2017
Thank you, JDB! I didn't know about VeraCrypt - I'll test it out! EDIT: It's a still-alive project, updated recently! Yay!
EDIT2: @JDB, I saw your comments in this thread about using Thread Count of 1, to avoid data corruption over USB3 - is this equivalent to FFS's parallel file operations option being set to 1? Is it risky to set parallel file operations higher than 1 in your experience?
EDIT2: @JDB, I saw your comments in this thread about using Thread Count of 1, to avoid data corruption over USB3 - is this equivalent to FFS's parallel file operations option being set to 1? Is it risky to set parallel file operations higher than 1 in your experience?
-
- Posts: 55
- Joined: 15 Feb 2018
Hello Darth, Sorry for my delay getting back to you. I don't know why the forum notifications didn't work.
I believe that my USB data corruption was actually caused by flaky USB 3 hardware and buggy driver code; perhaps exacerbated (and not CAUSED) by the increased load induced by setting higher parallel operations. I have since purchased a new USB 3 interface card, and so far have not experienced data corruption with parallel opterations set to 2. When I set parallel operations higher than that, FFS pretty much consumes the whole system, so I now keep it at 2.
FYI: The old hardware and driver (possibly buggy) was the ETRON EJ168 chip on my Gigabyte motherboard. The driver version was 1.0.0.119. When I tried to validate this, the highest driver version I could find online (through both Etron and Gigabyte) was 1.0.0.118. I haven't a clue how I wound up with a version 119, other than stumbling on some bogus download sites pushing their own modified versions of drivers. Did I really download from them in the past? Shame on me. Anyway, I restored the official 118 version of the driver, and the silent data corruption diminished, but didn't completely disappear. In every case, files differed by JUST ONE BIT between the source and backup copies. VERY STRANGE. (answer to the next logical question: YES, I ran memory diagnostics for 4 hours and there were no errors)
The NEW hardware is a generic PCI X1 board from Rosewill that uses a NEC/Renesas DP720201 USB 3 chip. So far I have not observed any corruption at all in backups made when connected to that USB 3 interface. Anyone looking into upgrading or adding USB interfaces should strongly consider a Renesas chip implementation.
-John
I believe that my USB data corruption was actually caused by flaky USB 3 hardware and buggy driver code; perhaps exacerbated (and not CAUSED) by the increased load induced by setting higher parallel operations. I have since purchased a new USB 3 interface card, and so far have not experienced data corruption with parallel opterations set to 2. When I set parallel operations higher than that, FFS pretty much consumes the whole system, so I now keep it at 2.
FYI: The old hardware and driver (possibly buggy) was the ETRON EJ168 chip on my Gigabyte motherboard. The driver version was 1.0.0.119. When I tried to validate this, the highest driver version I could find online (through both Etron and Gigabyte) was 1.0.0.118. I haven't a clue how I wound up with a version 119, other than stumbling on some bogus download sites pushing their own modified versions of drivers. Did I really download from them in the past? Shame on me. Anyway, I restored the official 118 version of the driver, and the silent data corruption diminished, but didn't completely disappear. In every case, files differed by JUST ONE BIT between the source and backup copies. VERY STRANGE. (answer to the next logical question: YES, I ran memory diagnostics for 4 hours and there were no errors)
The NEW hardware is a generic PCI X1 board from Rosewill that uses a NEC/Renesas DP720201 USB 3 chip. So far I have not observed any corruption at all in backups made when connected to that USB 3 interface. Anyone looking into upgrading or adding USB interfaces should strongly consider a Renesas chip implementation.
-John
-
- Posts: 27
- Joined: 26 Nov 2017
Thank you for the detailed explanation, John!
I really appreciate your input, as, without your help, I would never have heard about Veracrypt, or thought about the potential risks of parallel file operations. Guess I'm lucky that I haven't noticed any problems with my file transfers (yet! fingers crossed). It's slightly comforting to know that Donation Edition with its DRM isn't an absolute necessity, since the bonus of parallel operations is a mixed blessing!
I really appreciate your input, as, without your help, I would never have heard about Veracrypt, or thought about the potential risks of parallel file operations. Guess I'm lucky that I haven't noticed any problems with my file transfers (yet! fingers crossed). It's slightly comforting to know that Donation Edition with its DRM isn't an absolute necessity, since the bonus of parallel operations is a mixed blessing!
