Disk Partitioning

On Mon, 30 Sep 2013 14:01:03 -0700, "Gene E. Bloch"
wrote:

On Sun, 29 Sep 2013 10:27:49 -0700, Ken Blake wrote:

On Sun, 29 Sep 2013 11:15:01 -0500, Char Jackson
wrote:

And believe me (hah!) there is nothing new in what I described.

But I'm more reluctant to trust you on that. I don't think it always
worked that way, and what I described was the way it used to work.

I don't remember a time, or a specific program or scenario, where what you
described was an issue. It could have been and I simply wasn't aware of it,
but it doesn't sound right.

Note that I said "*I don't think* it worked that way" I didn't say I
was sure.

As in "what I described was the way it used to work"? There was no "I
think" in front of that.


Notice the "I think" at the beginning of the sentence you quoted.

Yes, I could have written a better, clearer sentence.

Ken

On Mon, 30 Sep 2013 14:42:06 -0700, Ken Blake wrote:

On Mon, 30 Sep 2013 14:01:03 -0700, "Gene E. Bloch"
wrote:

On Sun, 29 Sep 2013 10:27:49 -0700, Ken Blake wrote:

On Sun, 29 Sep 2013 11:15:01 -0500, Char Jackson
wrote:

And believe me (hah!) there is nothing new in what I described.

But I'm more reluctant to trust you on that. I don't think it always
worked that way, and what I described was the way it used to work.

I don't remember a time, or a specific program or scenario, where what you
described was an issue. It could have been and I simply wasn't aware of it,
but it doesn't sound right.

Note that I said "*I don't think* it worked that way" I didn't say I
was sure.

As in "what I described was the way it used to work"? There was no "I
think" in front of that.

Notice the "I think" at the beginning of the sentence you quoted.

I did: "I don't think it always worked that way, and what I described
was the way it used to work."

But it was "I don't think", and it modified "it always worked that way".

I didn't notice an "I think" modifying "what I described was the way it
used to work", and I still don't see one.

Yes, I could have written a better, clearer sentence.

Me too :-)

But seriously, if any programmer who worked for me had written an
incremental BU program that worked that way, I probably would have fired
him or her - even half a century ago.

Or more realistically: if I had owned any incremental BU program that
worked that way, I probably would have dumped it, even in 1995.

--
Gene E. Bloch (Stumbling Bloch)

Gene E. Bloch wrote:
On Sun, 29 Sep 2013 13:07:26 +0100, Ed Cryer wrote:

Gene E. Bloch wrote:
On Sat, 28 Sep 2013 07:37:39 -0700, Ken Blake wrote:

On Fri, 27 Sep 2013 17:33:38 -0700, "Gene E. Bloch"
wrote:

On Fri, 27 Sep 2013 07:44:22 -0700, Ken Blake wrote:

On Thu, 26 Sep 2013 20:05:52 -0700, "Gene E. Bloch"
wrote:

On Thu, 26 Sep 2013 21:18:00 -0500, Char Jackson wrote:

On Wed, 25 Sep 2013 18:42:06 -0700, "Gene E. Bloch"
wrote:

On Wed, 25 Sep 2013 19:50:28 -0500, Char Jackson wrote:

On Tue, 17 Sep 2013 08:05:46 -0700, Ken Blake wrote:

I am generally against incremental backup. It backs up only those
things that need to be backed up, and that's good.

But what's bad is that if you restore from it, you get back files
you've deleted. That may not always be a problem, but it can be.

I'm glad a couple of folks questioned that last part. It made no sense to
me. I apparently wasn't alone.

Ken Blake pointed out a scenario where that made sense, in

Message-ID:

If you back up a partition, then delete a file from it, then restore it
from that backup, you get the deleted file back.

It was then pointed out (by others) that this is a characteristic of
*any* backup method. Oddly enough :-)

To me, the fact that a backup contains everything that it contained as of
the time of its creation is one of those 'duh' moments, not really worth
mentioning and certainly not worth characterizing as a problem, but there's
room for differing opinions.

Well, I quite agree with you about the duhness of it, but (to a small
extent) I've been holding my tongue :-)

I've been waiting for someone else to point out what I was talking
about, but since nobody did, I will.

To use a simplified example, let's say there are two computers, each
with three files, A, B, and C. One computer (#1) uses full backup,
the other (#2)) incremental.

Both computers do a full backup (when you do incremental backups, you
start out with a full backup). Files A, B, and C are still on both
computers and both backups.

Then you modify C and delete B from both computers. Both computers now
have A and C.

You do a full back on computer #1, and you have A and modified C on
the backup. You do an incremental backup on #2 and all you get is the
modified C.

Both computers crash and you restore from their backups. Computer #1
gets A and modified C restored. On computer #2, you begin by restoring
the full backup--A, B, and C--and then the incremental backup, which
modifies C.

Computer#1 (the full backup computer) now has A and modified C on it.
Computer #2 (the incremental backup computer now has A, B, and
modified C on it.

You missed how it works.

When you restore from an incremental backup, the backup program uses the
data it saved with the backup image files to figure out what the exact
state of the source system *when that incremental backup was made*. It
does *not* restore A, B, and C because *it knows* that B was deleted
before that incremental backup was made. Only A and the current C are
restored.

When you said above, "You do an incremental backup on #2 and all you get
is the modified C" you are wrong. You get instead A, the modified C, and
a notation that B has been deleted.

Not to say that you are definitely wrong, because I don't know that
for sure. But if you could point me toward a link that says that, I'd
appreciate seeing that.

And if what you say is true, it's very likely a relatively new thing.
I'm almost sure it didn't always work that way.

I can testify that it's true because I have verified it with my own
software, but I don't know of any links to give you, and don't intend to
try to find any. You'll have to choose to trust me or not to.

And believe me (hah!) there is nothing new in what I described.


So how does it cater for the situation that Ken outlined?
I'll reduce it to its simplest terms; a deleted file.
You have a. the full backup and b. the incremental backup with a file
deleted.
Do a restore to the time of the incremental backup, and what tells it
about the deleted file?

Ed

It has already been explained ad infinitum by me and others, so here's
my last attempt.

The backup program keeps a record of the state of the source drive as
part of the incremental backups it creates. It uses that info to create
an exact picture of what the disk or partition looked like at the time
of backup, and that is what it will restore.


It was I who introduced that. I brought VSS into the light of day for
this discussion. I showed why it was necessary and how it operates. At
the point when I came in there were open questions about theoretical
problem areas, and I saw straight away that a proper explanation and
understanding of just how the incremental backup works in Win7 would
dispel them.

I was hoping to go further and look at the operational losses of having
VSS running; how it slows things down. But now we've descended into a
mess of recriminations and self-defence, so I doubt we'll get there.

Ed

On Mon, 30 Sep 2013 23:51:26 +0100, Ed Cryer wrote:

So how does it cater for the situation that Ken outlined?
I'll reduce it to its simplest terms; a deleted file.
You have a. the full backup and b. the incremental backup with a file
deleted.
Do a restore to the time of the incremental backup, and what tells it
about the deleted file?

Ed

It has already been explained ad infinitum by me and others, so here's
my last attempt.

The backup program keeps a record of the state of the source drive as
part of the incremental backups it creates. It uses that info to create
an exact picture of what the disk or partition looked like at the time
of backup, and that is what it will restore.


It was I who introduced that. I brought VSS into the light of day for
this discussion. I showed why it was necessary and how it operates. At
the point when I came in there were open questions about theoretical
problem areas, and I saw straight away that a proper explanation and
understanding of just how the incremental backup works in Win7 would
dispel them.

I was hoping to go further and look at the operational losses of having
VSS running; how it slows things down. But now we've descended into a
mess of recriminations and self-defence, so I doubt we'll get there.

Ed

And it was I who got hopelessly confused :-)

I somehow thought I was talking to Ken, partly because I thought I was
reading a defense of his understanding of how things worked, and partly
because I was careless.

By now, I owe apologies to both of you, and I do apologize to you both.

But I remain too confused to figure out where I went wrong...

As for Macrium (and they too must hate me for what I'm about to say), I
believe that when a backup is started by the user or by the scheduler,
Macrium starts the VSS service[1] to create an image map (or however VSS
does its magic) which then determines the file structure and contents
that get backed up (imaged or cloned, that is). That is how one can
continue to work while a backup is happening without messing up the
result.

I believe it works like that because that's how I interpret the messages
that Macrium displays at the beginning of its operation when I am there.
Of course I believe that a scheduled operation is no different.

There are some obvious experiments that I haven't done. In particular, I
could create, delete, or rename a file or files after the actual copying
operation starts and look to see what is in the image or clone later,
but I prefer to do nothing at all during the backup. It's not a rule; I
occasionally do other things, even things as desperate as posting on
Usenet, during a backup.

[1] I *think* it's VSS...anyway, there are messages about creating an
image of some sort. I'll look next time (probably before the end of the
year).

--
Gene E. Bloch (Stumbling Bloch)

Gene E. Bloch wrote:
On Mon, 30 Sep 2013 23:51:26 +0100, Ed Cryer wrote:

So how does it cater for the situation that Ken outlined?
I'll reduce it to its simplest terms; a deleted file.
You have a. the full backup and b. the incremental backup with a file
deleted.
Do a restore to the time of the incremental backup, and what tells it
about the deleted file?

Ed

It has already been explained ad infinitum by me and others, so here's
my last attempt.

The backup program keeps a record of the state of the source drive as
part of the incremental backups it creates. It uses that info to create
an exact picture of what the disk or partition looked like at the time
of backup, and that is what it will restore.


It was I who introduced that. I brought VSS into the light of day for
this discussion. I showed why it was necessary and how it operates. At
the point when I came in there were open questions about theoretical
problem areas, and I saw straight away that a proper explanation and
understanding of just how the incremental backup works in Win7 would
dispel them.

I was hoping to go further and look at the operational losses of having
VSS running; how it slows things down. But now we've descended into a
mess of recriminations and self-defence, so I doubt we'll get there.

Ed

And it was I who got hopelessly confused :-)

I somehow thought I was talking to Ken, partly because I thought I was
reading a defense of his understanding of how things worked, and partly
because I was careless.

By now, I owe apologies to both of you, and I do apologize to you both.

But I remain too confused to figure out where I went wrong...

As for Macrium (and they too must hate me for what I'm about to say), I
believe that when a backup is started by the user or by the scheduler,
Macrium starts the VSS service[1] to create an image map (or however VSS
does its magic) which then determines the file structure and contents
that get backed up (imaged or cloned, that is). That is how one can
continue to work while a backup is happening without messing up the
result.

I believe it works like that because that's how I interpret the messages
that Macrium displays at the beginning of its operation when I am there.
Of course I believe that a scheduled operation is no different.

There are some obvious experiments that I haven't done. In particular, I
could create, delete, or rename a file or files after the actual copying
operation starts and look to see what is in the image or clone later,
but I prefer to do nothing at all during the backup. It's not a rule; I
occasionally do other things, even things as desperate as posting on
Usenet, during a backup.

[1] I *think* it's VSS...anyway, there are messages about creating an
image of some sort. I'll look next time (probably before the end of the
year).


You're a gem, Gene. I was about to post an apology myself for having
entered a discussion in mid-stream and maybe having thrown everybody.
The thing I wanted to avoid at all costs is the situation where we all
end up surveying the thread trying to ascertain who said what, to whom,
at what time relative to the other posts; and end up more muddled than ever.

One of the things causing confusion is terminology. I'm all at sea with
"image", though I see MS use it and winston used the term "image
pointer". Others use "snapshot" and "copy".

Another problem is what you might call the "level of perception";
user-friendly overview or what actually happens on the ground.

Pax
Ed

On 17/09/2013 12:09, Steve Hayes wrote:
snip
XCOPY C:\BELFRY\*.* H:\BELFRY\ /E /Y

Ah so you have BELFRY's in your BATs eh?!
Makes a nice change compared to some of the posters here. ;-)
--
Rob

On Tue, 01 Oct 2013 12:57:34 +0100, Ed Cryer wrote:

snipped to save paper

You're a gem, Gene. I was about to post an apology myself for having
entered a discussion in mid-stream and maybe having thrown everybody.
The thing I wanted to avoid at all costs is the situation where we all
end up surveying the thread trying to ascertain who said what, to whom,
at what time relative to the other posts; and end up more muddled than ever.

Thanks for the first remark!

The rest of the paragraph summarizes to a T how I was feeling when I
wrote my post :-)

One of the things causing confusion is terminology. I'm all at sea with
"image", though I see MS use it and winston used the term "image
pointer". Others use "snapshot" and "copy".

Quick summary of some terms:

image = a backup[1] in the form of a file that is not a literal copy of
the disk[2], but contains all the information that is on the disk, so
that the original backup program can recreate such a literal copy from
the file onto the original disk or a new disk. The image itself is not
bootable, but the recreated disk image can be bootable.

snapshot = data in memory that represents the contents of the disk at a
specific time, so that a backup procedure of any sort can create a
backup of the disk at that specific time even if later changes are made
to that disk.

copy = the act of transferring the data of a set of files to another
place as a new set of files whose contents are similar (preferably
identical) to the originals without removing the originals from where
they reside.

image pointer = I have no idea; ask ...winston.

[1] I am using this to mean generically any procedure that saves data so
that it can be reclaimed if needed.

[2] I am using this generically to mean any disk, partition, thumb
drive, unified set of clay tablets, or whatever.

ANNOUNCEMENT:
At this time, I am preparing to become a read-only follower of this
thread :-)

--
Gene E. Bloch (Stumbling Bloch)