file history
Amal,
This feature is going to be there in version 2.0, which is currently under beta testing.
There
will be one difference though. The files will are stored in reverse direction, meaning
the most recent version is kept as-is and previous versions are stored as delta. 99%
of the time a user will be restoring the most recent version and there is no point
in reconstructing from 30 files when this happens. If the user decides to restore
the first version, Syncrify will reconstruct the file from 30 prior versions.
>I'm interested in providing backup services to my clients using Syncrify and I noticed
>you've
got a "Partners" section on your website. I've used several different backup
>solutions designed for use in a partner/service scenario, and the one thing they
all
>have that Syncrify seems to be lacking is a file history feature.
>
>After reading this KB article; http://web.synametrics.com/syncrifymultiplecopies.htm
>it
seems to me that Syncrify takes a typical "rotation" approach to backup history
>window, where full copies of each file are stored in a separate profiles and manipulate
>a
schedule. This approach has one major problem in that it does not help maximize
>space on the server side. Full copies of each file will reside on the server for
each
>profile, which is really not ideal.
>
>Ideally it would be a good idea to implement a sort of "transaction log" approach,
>similar
to how a database engine works:
>
>- First, the client software must be updated to allow the user to create a profile
>with
a version and a retention setting. The user can specify they want modified files
>to retain the last 30 versions on the server side. They can also specify they want
>deleted
files to stay available on the server for up to 90 backup cycles. Let's assume
>a hypothetical situation and these are the settings the user has selected.
>
>- When the first backup cycle is run, full copies of each file are stored on the
server
>
>
> On the second cycle, "change log" style files are stored for each modified file.
>The
server receives the changed bits from the client but does not alter the original
>file on the server. Instead is stores these changed bits as separate date-coded binary
>files.
>
>
On the 31st backup cycle, the 30 version history has been exceeded, so the first
>binary
change file is integrated into the original full version of the file and a
>new 30th binary change file is written. This leaves you with a full copy of the file
>and
30 smaller binary change version files.
>
>- If the file is deleted, then the original file and the 30 change versions are kept
>according
to the cycle count set by the client's profile. After this count has been
>exceeded, the full copy and all binary change versions are deleted from the server.
>
>
>
Upon restore request, the server will dynamically reconstruct the version requested
>by
the client from the full file and binary change version files by copying the full
>copy
of the file to a temp file, then applying binary version changes until the requested
>version
has been reached, then the temp file is served back to the client for restoration.
>
>This
>approach
maximizes storage space on the server, allows a more flexible method of establishing
>a
backup history, and offers a much easier way to configure backup history to the
>client.
>
>Without this feature, it's hard for Syncrify to compete against other solutions when
>potential
partners are larger than 10-20 backup client customers in size.
