totally reliability or speed or?

User discussion and information resource forum for Image products.

totally reliability or speed or?

Postby TeraByte Support » Sat Nov 28, 2015 10:16 am

If people are interested, we can implement a old method of detecting changes
for both backup and restore that can be much faster but it is more
unreliable. It may be "good enough" for clean file systems but overall,
it's NOT "totally reliable". It would work for most cases, but you could
be burned by it, and has a chance of snowballing corruption (into your
backups) when using it for restores without you knowing it (e.g. thinking
you had a clean state after restore but really don't) .

It is the old method of using metadata to determine if changes may have been
made (e.g. dates and times, file locations (not needed for pure file based),
etc..). This method for backup and restore has been around since the DOS
day. It expanded to images (rather than pure file based) in the late 1990s
early 2000's as part of the deduplication movement; particularly to those
who wanted to provide services across slower links.

While the write tracking method recently added is not totally reliable, it's
a step above metadata. Before adding additional new options, new products,
or new companion programs based on metadata, we wanted to check to see how
much interest there would be in our user or potential user base for either
backup or restore or both. Do note that restoring using metadata should NOT
be used for disaster recovery (corruption, unexplained problems, hardware
failure) but more for, I have an image from x days ago and I haven't done
anything other than install or uninstall something that needs to be "undone"
(which to me seems more like a job for a "goback" or "rollback" utility
which is different than disk imaging). (side note: if you use one of these
along with disk imaging (being compatible), indicate what you use and how
well it works).

Don't worry, the totally reliable disk imaging methods won't go away, there
are way too many very important systems all over the world that rely on it.
Just making some decisions on 2016 (there are a lot of things that *could*
happen).


TeraByte Support
 
Posts: 2338
Joined: Thu May 05, 2011 3:37 pm

Re: totally reliability or speed or?

Postby jack450 » Sat Nov 28, 2015 12:10 pm

Reliability!! Although speed enhancement would be nice, it should never be at the expense of reliability. IFL is the only program I've ever used that has never failed me.
jack450
 
Posts: 34
Joined: Sat Apr 14, 2012 10:01 am

Re: totally reliability or speed or?

Postby Brian K » Sat Nov 28, 2015 3:09 pm

Reliability.

I doubt I'd even be interested in using a less reliable method on my test computer, despite it being a faster method. One of the opposition imaging apps uses "Rapid Delta Restore" which is popular in certain forums so speed matters to that group. I haven't used "Rapid Delta Restore". I don't know if it fits the "Reliability" criteria.
Brian K
 
Posts: 1185
Joined: Thu Aug 11, 2011 6:11 pm

Re: totally reliability or speed or?

Postby Bob Coleman » Sat Nov 28, 2015 3:12 pm

I don't think I'd use something that I know is less reliable.
Bob Coleman
 
Posts: 407
Joined: Fri Aug 12, 2011 10:58 am

Re: totally reliability or speed or?

Postby tas3086 » Sat Nov 28, 2015 3:50 pm

Absolute Reliability...
Would .... and should work ... are not the options that I would want to use. You usually do not find out that a problem was introduced until a long time later, and then, your do not know how, when or where the problem was introduced.
tas3086
 
Posts: 212
Joined: Mon Mar 19, 2012 11:15 am

Re: totally reliability or speed or?

Postby mjnelson99 » Sat Nov 28, 2015 6:22 pm

I like IFL if I shut down my PC. Otherwise, I use IFW.
Both have worked well for me.
Mary

On 11/28/2015 1:10 PM, jack450 wrote:
> Reliability!! Although speed enhancement would be nice,

it should never be at the expense of reliability.

IFL is the only program I've ever used that has never failed me.
>
>
mjnelson99
 
Posts: 771
Joined: Thu Aug 11, 2011 6:24 pm

Re: totally reliability or speed or?

Postby TeraByte Support » Sat Nov 28, 2015 10:45 pm

looking at the description it would appear to use the metadata so would fall
into something you would not want to use for any type of DR dealing with
corruption or problems. more for everything is good but want to go back to
a prior point in time type restore (remove new files, put back old/changed
files). just not sure how useful that is especially when things like
"goback" exists that handle every change as the occur.

"Brian K" wrote in message news:10591@public.image...

Reliability.

I doubt I'd even be interested in using a less reliable method on my test
computer, despite it being a faster method. One of the opposition imaging
apps uses "Rapid Delta Restore" which is popular in certain forums so speed
matters to that group. I haven't used "Rapid Delta Restore". I don't know if
it fits the "Reliability" criteria.

TeraByte Support
 
Posts: 2338
Joined: Thu May 05, 2011 3:37 pm

Re: totally reliability or speed or?

Postby TeraByte Support » Sat Nov 28, 2015 10:47 pm

ok, so far, it looks like it's all one direction.




TeraByte Support
 
Posts: 2338
Joined: Thu May 05, 2011 3:37 pm

Re: totally reliability or speed or?

Postby Froggie » Sun Nov 29, 2015 7:13 am

BOTH! :-)

As Brian_K has mentioned above, the RAPID DATA RESTORE (RDR) feature in a competing product is indeed a metadata-based imaging solution. There are two additional competing products that use a DIFFERENCE restoration technique but provides those differences via a FileSystem tracking mechanism. The "tracking file" implementations can have havoc played with them under the use of LV (Lite Virtualization) techniques as well as external FileSystem modifications (WinPE, LINUX, etc.).

The RDR method uses a FileSYstem comparison operation to determine the differences necessary to process, BUT... it also provides for a needed pre-imaging FileSystem check (mini CheckDsk) and if anomalies are discovered, aborts the imaging operation and informs the user to run a full CheckDsk to stabilize the file system. This is very important as FileSystems can easily carry "anomalies" that can later require the OS to take action to manage/repair. This operation has made the integrity of the RAPID DATA RESTORE technique very reliable. I don't know the ground level nitty gritty of the actual design technique, but after 250+ RAPID DATA RESTORES not a single FileSystem glitch has been discovered (two pre-imaging anomalies discovered during that time span).

I use the feature a lot mostly for snapshot requirements. I was a Rollback RX snapshot user for many years but the product is so prone to outside interference, Windows updates and the like, that the chance of losing your whole system and its important snapshot information is just too high to risk. It also defeats the use of the OS' TRIM subsystem for management of my SSD installations. This type of snapshotting subsystem is just too dangerous to use, IMHO, without a very reliable imaging system to back it up... and Rollback even makes that a very difficult process to perform without lots of hoops to jump through.

Having tried the other above implementations of DIFFERENCE restoration techniques, RAPID DATA RESTORE has become my GoTo snapshot solution. As a long time IFW user, it has always been my most important imaging solution, but in my System operating environment, I really require fast restoration techniques for snapshotting and RDR has become that solution... for the moment.
Last edited by Froggie on Sun Nov 29, 2015 12:14 pm, edited 3 times in total.
Froggie
 
Posts: 15
Joined: Mon Apr 27, 2015 5:04 am

Re: totally reliability or speed or?

Postby Froggie » Sun Nov 29, 2015 7:24 am

...and to add to the above (and I don't know the design criteria here so forgive me <or correct me> for my assumptions)

IFW indeed appears to check for pure differences when imaging (INCREMENTAL) a volume and images REAL differences to the image file. While this is great for integrity (pure differences only in volume data), it also means that any of the FileSystem anomalies that may exist will also be "purely" imaged, leaving you with an anomalous FileSystem upon restoration (same as you had when you started). This is a good thing as far as real imaging is concerned (I think :-) ), but with the addition of some checks along the way (aka RDR), could be made much better in its ultimate performance and accuracy.
Froggie
 
Posts: 15
Joined: Mon Apr 27, 2015 5:04 am

Next

Return to Image for DOS/Linux/Windows