TeraByte Unlimited

On Sat, 4 May 2013 13:49:40 PDT, Brian K wrote:

>monkeyteeth,
>
>What have you got against differential images? They are easier to work with than incrementals.
>
Some points in favour of incrementals:-

1. On average they are much smaller than differentials.

For example, take a simplified case where there is 5MB of new changes
per diff/incr backup. (I'm using MB here, but the units don't matter
because we're interested in the comparisons between diff and incr
here.)

For 10 Diff backups where the size of each backup increases by 5MB,
total space taken by these backups will be 275MB.

For the corresponding 10 incr backups, the total space taken will be
50MB.

Quite a difference.



2. Because incrementals are on average much smaller, they will take
less time to complete.

In the example above, in the mid-point case (backup #5), the diff
would be 25MB, while the corresponding Incr would be 5MB; Less time to
write and less time to verify the incr.

For backup #10, diff size has increased to 50MB while incr size is
still just 5MB.


As to your point that "diffs are easier to work with than incrs", I
don't see that at all. On a restore, IFW automatically follows the
chain of image files back to the starting full backup regardless of
whether you've taken diffs or incrs.

If you are concerned that some image files may have become unreadable,
then this can happen in either case.

(To make sure all the previous image files back to the full are
readable, you can avoid using the 'speed up changes-only' option,
forcing the re-reading of the relevant previous image files when
taking a new changes-only image. Obviously the changes-only backups
will take longer.)

TAC109 wrote:

> 2. Because incrementals are on average much smaller, they will take
> less time to complete.
>

Tom,

In my computer, incrementals take longer to create. I just ran a few tests and the incremental was 18 MB compared with 954 MB for the differential. The incremental took 30 seconds longer to be created. I have stacks of backup space.

On Sat, 4 May 2013 16:28:04 PDT, Brian K wrote:

>Tom,
>
>In my computer, incrementals take longer to create. I just ran a few tests and the incremental was 18 MB compared with 954 MB for the differential. The incremental took 30 seconds longer to be created. I have stacks of backup space.
>
Some ideas:-

1. Is your 30sec difference a significant amount of time compared to
the actual backup time?

2. Was there a hash file available for use in both cases (created for
the /base linked file)?

As you know, IFW has no direct concept of diff vs incr other than the
/base linked file. If there was no hash file available IFW would need
to process the chain of files back to the full backup to determine the
current changes. (One file for diff, maybe more than one for incrs.)

3. You may need to run your tests a few times in varying orders to
minimise the effects of buffering, other processes running in the
background accessing disks, etc.

Tom,

I realized I was doing an unfair test. A hash for the differential but not for the incremental. OK, hashes for both. 2 minutes for the 1 MB incremental. 2.5 minutes for the 954 MB differential.

I prefer diffs as a restore only relies on two files. I've never had a problem restoring an incremental but the "long" chain of images makes me uneasy.

Differentials aren't as smooth conceptually for testing buildups. And take up more space.

On Sat, 4 May 2013 21:06:17 PDT, just as I was about to take a herb,
Brian K disturbed my reverie and wrote:

>I prefer diffs as a restore only relies on two files. I've never had a problem restoring an incremental but the "long" chain of images makes me uneasy.

Two things stopping me using incrementals:-

1) The inability to tell the difference between diffs and incs from
the file names or in the GUI

2) Ages ago, when I asked about incrementals, TBU was SO 'anti-', I
was gob smacked when they appeared.
--

Cheers,

DrT

** Stress - the condition brought about by having to
** resist the temptation to beat the living daylights
** out of someone who richly deserves it.

Here's a sample of how you could get the oldest file using TBScript - if you
save this script to a file with a .TBS extension, (e.g. newest.tbs) then run
it with the mask you want to test (e.g. run newest.tbs *.tbi)

sub main()
mask=arg(1)
// set default mask if none set
if len(mask)=0 then
mask="*"
end if

// indicate mask being used
print("Searching for the newest file matching " # mask # " ...")
// get newest file
newestfile=GetNewestFile(mask)
// move to next line
printl("")
// report what was found
if newestfile="" then
printl("No file found.")
else
printl("Found: " # newestfile # " " # newestfile.size # " " #
newestfile.date # " " # newestfile.time)
end if
end sub

//
// Find the newest file of a given mask. Returns an empty string
// if no files matching the mask were found.
//
sub GetNewestFile(mask)
// we'll set the newest file found to a variable named newestfile
newestfile=""
// start finding all files
f=findfirst(mask)
// while a file was found
while len(f) > 0
// skip directories
if (f.attrib & 0x10)=0 then
// reformat the date/time - unfortunately the are no members returned
// at the time of this example that can be used for sorting directly
f.sortabledatetime=MakeSortableDateTime(f.date, f.time)
// check if this files date is later than what we already have
if f.sortabledatetime>newestfile.sortabledatetime then
// yes so this is the newest file so far
newestfile=f
end if
end if
// move on to the next file
f=findnext(f)
wend

return newestfile
end sub


//
// Conversion of date and time formatted for display to one usable
// for sorting. This assumes locale using date and time formatted
// using mm/dd/yyyy and hh:mm:ss AM respectively
//
sub MakeSortableDateTime( date, time )
// split date to its parts (modifies date variable)
n=instr(date, "/")
mm=right("0" # mid(date, 1, n-1), 2)
date=mid(date, n+1);
n=instr(date, "/")
dd=right("0" # mid(date, 1, n-1), 2)
yyyy=mid(date, n+1)

// split time to its parts
n=instr(time, ":")
hh=right("0" # mid(time, 1, n-1), 2)
min=mid(time, n+1, 2)
ss=mid(time, n+4, 2)
ampm=lcase(mid(time, n+7, 1))
// handle conversion to 24hr format
if ampm="p" then
hh="" # hh+12
if hh="24" then
hh="00"
end if
end if

// return version usable for sorting
return yyyy # mm # dd # hh # min # ss

end sub







"monkeyteeth" wrote in message news:[email protected]...

> Can you be specific with what you want

As I mentioned earlier, automate incrementals. Reboot computer, pick
specially created bootitem that launches a script that simple takes another
incremental snapshot of a partition based on which bootitem I selected. To
complicate the issue, this partition may already have 5 incrementals, so
this would be creating the 6th incremental.

I've looked at /base from page 141 of IFD manual. It talks about combining
incrementals into single file. I don't see how it applies here. I don't see
another switch that gets get past the circular reference problem of calling
a file (say the 5th incremental...i.e. the last incremental), when the file
doesn't exist yet at the time the script is created. /savename would seem to
work, but it needs registry per manual. Can't a .ini file be saved in the
root of EMBR that IFD would save the results of /savename to?

Thank you.

On Sat, 4 May 2013 05:19:58 PDT, monkeyteeth wrote:

>> Can you be specific with what you want
>
>As I mentioned earlier, automate incrementals. Reboot computer, pick specially created bootitem that launches a script that simple takes another incremental snapshot of a partition based on which bootitem I selected. To complicate the issue, this partition may already have 5 incrementals, so this would be creating the 6th incremental.
>
>I've looked at /base from page 141 of IFD manual. It talks about combining incrementals into single file. I don't see how it applies here. I don't see another switch that gets get past the circular reference problem of calling a file (say the 5th incremental...i.e. the last incremental), when the file doesn't exist yet at the time the script is created. /savename would seem to work, but it needs registry per manual. Can't a .ini file be saved in the root of EMBR that IFD would save the results of /savename to?
>
We've hijacked your thread - sorry!

Returning to your questions, I'm not sure if you have purchased a
package and if so which package.

If it includes IFW, and you're a Windows user then the only publicly
available set of scripts that automatically handle incremental backups
that I'm aware of is IFW_Backup, available in the Scripting forum on
this site. (I am the author of these scripts.) Many of us use IFW to
back up our systems and have complete faith in this Terabyte product.

Although the IFW_Backup scripts are written in DOS batch and could be
easily modified to run IFD, they make use of the DOS extensions,
available in Windows 2000, XP and later, and would not run on earlier
versions of DOS.

On Sat, 4 May 2013 21:06:17 PDT, Brian K wrote:

>Tom,
>
>I realized I was doing an unfair test. A hash for the differential but not for the incremental. OK, hashes for both. 2 minutes for the 1 MB incremental. 2.5 minutes for the 954 MB differential.
>
>I prefer diffs as a restore only relies on two files. I've never had a problem restoring an incremental but the "long" chain of images makes me uneasy.
>
Brian,

Your new times make more sense.

You appear to be taking both incr & diff images on the same
partition(s). Are you conducting a test of the incremental method?

I'd be interested in reading of your results & conclusions.