Re: XP Pro Backup Utility - Not Quite Getting it


"Gary Walker" <twf@xxxxxxxxxx> wrote in message news:...

We're starting a small birthday celebration here shortly,
I'll take a look at the plans this evening(CST).

Gary



"Nomad" <nomad@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:34AFA1D5-113C-4868-B84E-B5DE705A9D0F@xxxxxxxxxxxxxxxx
ok. I've been reviewing your text some more and I'm wondering if you'll
indulge me by reviewing my game plan to see if I have this staight now.
And
thanks in advance for your great help if you have the time (or anyone
else
cares to join in this marathon of questions :). I am hugely thankful if
you
can help me.

I understand I will probably need ASR to totally 'bounce back' but in
thinking about things, I really just want my data if I crash/lose the pc.

So here's how I understand this and how I propose to go about things.

My first backup, which was a 'normal' backup of everything on the pc,
will
be named, let's say "Everything.bkf"
Now that I have that, my next backup will be an 'incremental' backup and
I
will again select the same files and folders to backup (really it's
everything again) but now name this backup file, "Weekly.bkf" (For my
needs,




If I understand that correctly, you're gonna' create a full
backup named everything, followed by an incremental
named weekly. It appears to me that weekly will be a
complete backup similar to everything. Actually, I'm
not even sure you can start an incremental backup
referencing a backup file(*.bkf) that doesn't exist.

If you're allowed to proceed they'll certainly be nothing
available in the referenced backup file to drive the incre-
mental selection. This absence, of course, will result in
a full, unconditional selection.




I only really need to backup what has changed once a week)
Here's the part I get a little shaky on . . .
I have now run two backups and created two backup files.
A week has passed since I created "Weekly.bkf".
So now I run backup utility, select the same files and folders to backup,
set an 'incremental' backup, and SET THE TARGET TO 'Weekly.bfk"?? (then
repeat every week hence). By set the target, I mean that this backup has
the
same directory path and name (like copying over?) the last incremental
'Weekly.bkf" file which seems a little funny to me - but this is where
I'm
fuzzy on things.

If I understand correcly, between these two files, I have a complete
backup.
Ofcourse, at some point in future, "Weekly.bfk" will get so large I will
probably want to start this whole process fresh again. Is this a workable
scheme?





Actually, there's not reason to overthink this. If you only
want weekly incremental backups then follow this:

1). Start and complete a normal backup, called backup.
2). Start and complete an incremental backup named
backup.
3). Repeat #2 at the desired frequency, and for a pre-
determined length of time. Say, 1-2 months.
4). At that time, return to #1, and repeat the entire proc-
ess again.

However, I would suggest that a weekly incremental
just might be a little sparse. You're the expert on your
data, but I would never stay with that exposure. It only
take seconds to incrementally backup megabytes of
data. Why create any unnecessary risk exposure to
loss?




I think maybe I'm confused about exactly what happens to the files in the
'Weekly.bfk' when you do an 'incremental' backup over it with the same
target
name. If I am totally 'writing over' (wiping out) the "Weekly.bkf" every
week, then I would be missing some of my source files backups that
changed
after the 'normal' backup but not after one of the previous 'Weekly.bfk"
.. .




No, nothing is being overwritten. The incremental creates
a completely new directory path structure for the day the
incremental is run. Without being too verbose, if you
look internally at *.bkf file that contains 6 baclups(1
base/normal, and 5 incrementals), and the subject of
the backup was C:, you'll see 6 C: subdirectories.

Within each of those individual subdirectories will be
contained the various additional subdirectories/members
comprising the complete backup.

As example, using the previous example, "win.ini" will
appear in your #1 normal backup image. But, will not
ever appear in any subsequent incremental backup(
assuming win.ini never changes). Conversely, if a data
file called "my.txt" were created just before incremental
#3, my.txt would appear in #3's backup image. But,
my.txt would have never appeared in the #1's backup
image, because my.txt had not yet been created.

Additionally, if you modify my.txt just after #3's incre-
mental backup, it will also appear on #4's backup image.

So, with a restore/recovery of my.txt in mind, you'll have
to start the restore and then look for my.txt in the #1
backup image. Not finding it there, you'll have to look
through each backup image(#2-#6) until you find the
my.txt copy. Finding copies in both #3 and #4, you'll
then decide do you want #3 for previous recovery, or
the #4 copy for the latest restore?

Yes, the backup size continues to grow over time. How-
ever, in my opinion, this is not the problem. It's the look-
ing through all the incremental images to find the correct
cop/y/ies of what I want to restore. Of course, if you
choose to perform the full restore, this searching/looking
is not necessary. You simple restore the #1 backup
image, followed by the #2-#6 backup images.

I have relocated all my user data off of this PC's internal
drive. The internal drive contains only OS related stuff.
If I have an internal drive failure(as I did just recently),
I want to just image the OS and carry on with the external
user data. I just experienced a new PC failure that
caused a re-ship back to the manufacturer. As a result
of the internal drive containing all my/our sensitive infor-
mation, I had to change passwords/change accounts/
and place fraud alerts on my credit records. This is what
prompted the move to sensitive data being externally
stored.




since the instructions say, . . "An incremental backup backs up only
those
files created or changed since the last normal or incremental backup."
Hmm,
this shouldn't be rocket science :)





It's not rocket science. It's not even low level science.




As a side question, I guess I'm not sure exactly what the 'normal' type
backup does? Is it's purpose only to copy off everything you selected
(whether changed or not) and then leave behind the 'cleared archive
attribute' to set the stage for future 'incremental' backups?




Like I said earlier, I'm not aware of any relationship
between backup and archive posting. That's not to
say it's not there, I'm just unaware of it. But, it makes
sense that it doesn't exist. In the final analysis, the
decision as to whether to incrementally backup a file
stands with the determination of file's content. So, how
could archive indicator influence this to make it right or
wrong. It can't....




The MS Help
says "You usually perform a normal backup the first time you create a
backup
set."

Assuming the 'normal' backup type, always just backs up everything you
select (regardless of changed or not), I would REALLY like to avoid
creating
a everything backup using 'normal' backup because my equipment and gig
size
makes that a 15 hour deal. Maybe, after my first 'normal' backup to
"Everything.bfk", I really just want to create another everything
selection,
set it as 'incremental' backup, and then target to my "Everything.bfk"
file?
Would that meet my goals if I did that weekly?

Thanks for your consideration
--





You previously stated that you laptop contained 36gb.

Now, you're saying it's a 15hr job to run that 36gb out
to an external drive, via a USB link.

Something's wrong.... Without doing the math, when my
internal drive contained user data, it was about 20gb. I
used to run the normal backup on Sunday evenings in
preparation for the next weeks daily incrementals.

To complete that 20gb backup to a USB2 linked exter-
nal, took no more than about 15 minutes. So, using some
simple forecasting, I should have been able to do 40gb
in no more than 35-40 minutes easily. Remember, USB2
is 480mbps, earlier USB was <= ~12mbps, and a fire-
wire connection is ~400mbps(as I recall).

Let me see if I can do this calculation without screwin' it
up....

Your drive has 36gb, technically that's 36 * 1, 073, 741, 824. So, that's
38, 654, 705, 664. Each byte has 8 bits,
so that's 309, 237, 645, 312.

The unimpaired/optimum speed of USB2 is 480mbps.
That's 480 * 1, 048, 576. That's 503, 316, 480.

So, 309, 237, 645, 312 / 503, 316, 480 is 614.4 seconds. And, that's 10.24
minutes.

Obviously, you'll not complete the backup in 10 minutes,
but that's a long way from 15 hours. You do have some
processing overhead, which is an unknown variable.

Doing the calculation for USB1.0 is:
1.5 * 1, 048, 576 is 1, 272, 864. 309, 237, 645, 312 /
1, 272, 864 is 242, 946.33 seconds. And that's 67 hours,
29.1 minutes.

And, the calculation for USB1.1 is:
12 * 1, 048, 576 is 12, 582, 912. 309, 237, 645, 312 /
12, 582, 912 is 24, 576 seconds. And that's 6 hours,
49.6 minutes.



Thanks,


Gary



"Gary Walker" wrote:


Well, I'm no expert in backup, but I do use it every day
in various flavors, and have used it for restore also....


"Nomad" <nomad@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C679271C-E681-4989-8E87-30EC68FCA67B@xxxxxxxxxxxxxxxx
I started a 'backup the entire computer' operation on my laptop to an
external hard drive. It's clicking away and now I'm not so sure this
was a
great idea (for one thing, I have 36 gigs of data on the entire
computer
and
I have to wonder if all this churning might do in my computer before
it's
even 'safely' backed up :P




I doubt that any harm is about to come to your laptop,
other than a battery depletion. I assume you're running
with AC power. I also assume this Ext.HD is USB.

Of course, it's best if this is USB2, not USB1.x.



Question 1 - I just want to have an entire backup if my computer
crashes
or
is even stolen (assume the external hd with backup is kept in another
location). Is this a truly workable utility to be able to do that?




Yeah, but...

With what you've described you will not be able to rest-
ore the entire OS upon a failure/theft/etc. Although I've
not experimented with this, you'll need something called
an (A)utomated (S)ystem (R)ecovery image.

Based on what I read, and you can see by review of the
Backup help documents on the topic of ASR, this seems
to be a bootable stub that you store away until needed.

When the time comes, it sounds like you'd boot this ASR
image and use the minimal system to restore components
from your periodic backup. Perhaps someone else can
elaborate/correct my assumptions here. Unfortunately,
again referring to the ASR documentation, a 1.44mb
FD will be required for the ASR image recording. I due
recall playing with this once, but I don't have that drive.

It seems that a CD/DVD could be substituded for this
drive requirement, but I don't recall the experimentation
experience. It seems like, as I recall, it really means a
1.44mb diskette - no exceptions.

Of course, my plans regarding any restore needs would
be precluded by an entire system reload using shipped
distribution media. Then, user data would be restored
from there. Of course, I will lose any/all updates applied,
but those can be re-applied.



Question 2 - I don't understand how I go forward next time I want to
do a
backup when my laptop by then has new and changed files. I know I
should
use
what they call an 'incremental' backup, but I don't understand if I
will
backup to the SAME file name I used for this first backup (eg.
"Everything.bkf") or if I will backup to a NEW backup file name? I
could
understand if it was the SAME file - and it would only replace/update
the
changed files and also add the new ones. But if I'm supposed to create
a
NEW
file, I am confused on how anyone could perform an efficient restore
operation from what would end up being many, many '.bfk' files (having
multiple versions of the same backed up [but modified since] files).




The subsequent backup(s) always point to the initial bac-
kup(*.bkf) file for the incremental backup. I run this inc-
remental backup for a week, beginning the new week
with an overlay(normal) backup. My reason for this is:

If you've completed 6 incremental backups, and then just
simulate a restore to look at the .bkf structure, you'll see:

There will be 6 distinct images for your full backup target.
The first image will be the base image, containing your
complete backup target. The other 5 will contain comp-
lete directory images of your backup target but, only the
members changed will be included in the respective dir-
ectories. So, if you want to fully restore 1 complete dir-
ectory, you really should restore image #1, followed by
#2, #3,.... #6, in that order. Of course, if you know the
data, and what you're looking for, you could just restore
#3, or #5. But, depending on the member update activity,
#4 might be the last backup to contain the member that
you are/were looking for. If you merely continue to run
daily incrementals for say - 100 days, you're gonna' have
100 full path incrementals to look through to find the last
version of a specific member you might be tracking.

Using this structure has the benefit of both incremental
backup, and versioning. A single member may have ch-
anged on every day of your daily backups, and you'd
have 6 copies of that member. Each in various stage of
change. If the incremental was simply a member overlay
based on change activity, you'd have no versioning
recovery path.

With the backup execution, a text document log entry is
created to record the details of the backup. These log
entries are placed in an "ntbackup" directory in a 10
entry rotation. When the 11th backup rolls out, the 1st
backup log gets overwritten.

One other possibly important issue is that if you choose
to restore a single member/directory/etc. unless you
specify "single folder" mapping, the entire path get re-
built. This means that all the higher lever "empty" direct-
ories will be part of the restore package.



Question 3 - BONUS question :) Does anybody know what will happen if I
hit
the cancel button now that I've started this backup? (You can assume I
use
the backup type that clears the Archive checkbox attributes).
Specifically,
will what has already backed up be good and can I later continue with
the
rest of the backup? This has alot to do with Question 2 since if maybe
if
I
just backup to the same backup file name as an 'incremental' backup,
it
would
seem I'd be good to continue the backup?




I really don't know the answer to that, but I really don't
think backup interacts much/any with archive. IOW, I
don't think the archive setting carries any weight in the
backup operation. I think the backup is driven only by
the specified target, mitigated by any update activity.



Thanks,



Gary



Thanks for helping me.








.