Mirror ->> (with compression)

Discuss new features and functions
Posts: 5
Joined: 7 Sep 2010

elecpic

There is already a feature request for "[404, Invalid URL: https://sourceforge.net/tracker/index.php?func=detail&aid=2962123&group_id=234430&atid=1093083]"
Based on the comments of this request, it seems tricky to add such a feature
which can compare files within archives (compressed files). However, allowing
to compress and maybe encrypt all the destination files when performing a
Mirror ->> sync operation should not be too difficult. From my
understanding, the Mirror ->> sync deletes all existing files in the
destination folder before copying the source files. This could be nice backup
feature to add quickly while we're waiting for the full featured one. In fact,
this is what the most sync software have as compression support.
I wonder if one of you have already implemented this with a wrapper script to
a ffs_batch file? If you do, you should post an example of your script. It
could be very useful ;)
User avatar
Site Admin
Posts: 7052
Joined: 9 Dec 2007

Zenju

> deletes all existing files in the destination folder before copying the
source
It's a bit more elaborate: It is a two step process: 1. It processes all rows
that effectively lower hd space usage. This can be files that are deleted OR
small files that overwrite large files. 2. the rest

>a wrapper script to a ffs_batch file
I don't have a script as I mount encrypted volumes manually, but creating one
should be easy:
http://www.truecrypt.org/docs/?s=command-line-usage
Using TrueCrypt handles "encryption" and "compression" if the encrypted volume
is NTFS. The host volume holding the encrypted data file can be any other file
system format.
Posts: 5
Joined: 7 Sep 2010

elecpic

> Using TrueCrypt handles "encryption" and "compression" if the encrypted
volume is NTFS.



TrueCrypt looks like a very powerful and useful tool for encryption. I
understand how I could use NTFS compression within an encrypted volume and it
seems pretty easy.
The major inconvenient is that NTFS compression ratio doesn't rival any basic
compression methods. Even Zip compression is like 5 times better.
When I backup something, I don't really care how much time it takes to
compress/decompress the files as I can schedule the task. I just want to keep
it safe and small.
User avatar
Site Admin
Posts: 7052
Joined: 9 Dec 2007

Zenju

> compression ratio doesn't rival any basic compression methods.
I personally handle it by keeping all programs and tools as multiple .rar
files located on an encrypted backup volume. FFS's use is then to mirror these
archives to yet another backup HDD for data safety. This fulfills all three
requirements, encryption, compression and backup.