Re: Partition Magic Incompatibility??

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

On Sat, 24 Dec 2005 09:47:11 -0500, "Anna" wrote:
>"Stu Culp" wrote in message

>>I just took delivery of a new system with Windows xp, sp2 and two 120 gig
>> SATA hard drives. Since the os was set up to use all of drive 1 I
>> repartitioned it with Partition Magic so has to have a smaller c:
>> partition and then an extended partition with d:, e:, and f:. The second
>> drive was set up as an extended partition with logical drive g:, to be used
>> for backups.

Sounds good, though it's not a spec I'd have chosen if I was not
chained to an OS that wasn't OK > 137G. One 200G would have been
cheaper than 2 x 120G, or I'd have gone 2 x 200G.

I like your partitioning approach, though. I use BING
(www.bootitng.com) instead of PM, though; it works as well, and the
pricing and vendor relations are less bloody-minded than PM.

>> I had no end of problems: The floppy drive wouldn't respond, the video
>> would only play tv for about 5 minutes before freezing and locking up the
>> system and the dvd would only transfer large files (from my old computer
>> to the new using DVD/RW) without locking up and freezing the system
>> after several minutes of downloading. In addition, the ATI configuration
>> utility said that DMA was not enabled on the hard drives (it was).

I cannot see the connection with PM here; more likely something was
disturbed when moving hardware around, or damaged if you were doing
this with the mains plugged in and the system "off" (ATX "off" isn't)

I would not allow Windows to boot again, until I'd left this PC
running MemTest on all tests overnight without errors or hangs, and
seen the HD passed as faultless via www.hdtune.com

>> I took the system back to the dealer, and his suspicion was that Partition
>> Magic had screwed up the system. The solution was to wipe everything
>> clean and start over.

Sounds like a dealer to avoid.

>> Since the disk manager in windows xp won't resize partitions, I will have
>> to basically waste most of the c: drive unless I use Partition Magic

False; PM is not the only fish in the sea, and just because MS don't
make it, doesn't mean it can't be done.

>We do *not* use PM for partitioning purposes involving new/unpartitioned
>drives. In those cases we either use the XP installation CD where the OS
>is being installed on the drive or in the case of a secondary HD about to
>be installed we use XP's Disk Management utility to partition/format.

I use BING instead of XP there, because XP is too useless to create
and format volumes larger than 32G with FAT32 as the file system.

>It sounds to me like your dealer has the right "fix" at least at this point.

A dealer who summarally destroys an installation as a first "fix" is
one that I wouldn't brake for on the highway.

>Time will tell if there's a hardware problem after you get the computer back.

Hardware diagnostics have been known to help too. Did your dealer
bother to run any, and tell you what they found? I agree that some
components are inherently untestable (mobo, SVGA, PSU etc.) so that
you may still have to wait-and-see after diagnostics pass what can be
tested, but it disturbs me that you didn't mention such tests at all.

>But the real purpose of my response to you is to get you thinking about
>another backup strategy once your machine is back & running. Since you have
>two internal HDs, consider using a disk imaging program such as Symantec's
>Norton Ghost or Acronis True Image, to "clone" the contents of your
>day-to-day working HD to your second HD. Having (in effect) a bit-for-bit
>copy of your working HD on a second HD will give you the kind of peace of
>mind that's hard to get using any other backup system. And thereby achieving
>that new-found safety & flexibility, you may want to rethink your present
>partitioning scheme.

There's a lot of pros and cons here, and I see one of the most common
fallacies in the above - that creating a backup of everything is
enough to ensure successful recovery.

Building a backup is only half the story. You also have to be able to
not only restore that backup, but also use that material short of a
full restore to fix minor problems without unacceptable colateral
damage. A "full system backup" that can only be used to wipe and
start over, is going to be near-useless if all you wanted to do was
recover a single data file you lost a week ago, before creating lots
of new data and/or installing new software.

First up is the question of image vs. file backups.

Unlike Win9x, XP is too fragile to survive a file-level backup and
restore, so you are obliged to do an image backup of C: (or possibly
both C: and whatever volume the OS is installed on - I don't know
where the fragility is sited).

Image backups are a pain, because they are large, and difficult to
pull data out of without steamrolling the whole image back in place.
You can get cheap or free tools to spawn and restore full image
backups, though typically these operate outside of Windows; I don't
think any of these allow the image copy to be browsed as if it was a
"live" file sytsem, so that loose files can be restored.

So for this reason, I like a small C: containing the OS, and all data
held off C: on other volumes. That way, C: is smaller and faster to
image, repair via post-bad-exit AutoChk, defrag and so on, plus the
storage requirements for the image backups are less onerous. With an
8G C:, multiple images of various dates can be held in a single 90G
volume on the same HD, or separate HD, and if the contents of C: are
small enough, a "smart" image may fit on a DVDR, allowing unlimited
old-date image backup retention with zero HD footprint.

Next is backup depth and survivability.

The backup concept is to retain all wanted changes while losing all
unwanted changes. How is this magical outcome to be achieved? The
key is scoping out unwanted changes from wanted ones.

The normal scope is time. The idea is that unwanted changes will come
to light immediately, and there will be a backup that is free of such
changes, while recent enough for lost wanted changes to be an
acceptable loss. This approach is poorwhen dealing with malware that
may be entrenched and pervade all backups for months, before hatching
a destructive payload - blind backup/restore is generally poor there.

So you want to scope things differently, to manage situations where
the unwanted change extends far back in time, and/or you cannot afford
to lose all wanted changes applied since the restore point.

A good way to scope is to isolate data from version-bound,
hardware-bound and infectable code. That way, you can always safely
restore your data even if the software version changes, a different
replacement PC is to be used, or the system was riddled with malware.

Using partitioning to locate data off C: is a good start to this
process, which continues through data hygiene, i.e. ensuring the
backed-up data is malware-free.

If the backups are small enough to fit on cheap removable media, you
can keep an unlimited number of backups from different dates. A small
C: means you can do this on DVDR, hopefully without having to span
disks, and a small data set means you can hold file-level (browsable)
data backups on CDR or even (shudder) 1.44M diskettes.

If the backups are too large, so that you are forced to store and keep
only one backup at a time, then things are far less rosy - and that's
what I have against Anna's solution of two 120G HDs with one being
imaged over to the other, or (a refinement to assist survivability of
disasters that might eat the entire PC) a "live" HD that is imaged to
an external HD. Typical one-shot backup storage include HDs, whether
these be real-time (RAID 1), internal or external, and USB sticks.

Next is backup useability.

You want a backup that can be browsed, so that loose files can be
picked out and restored. This is to better manage small hassles, such
as the corruption of one file, as opposed to dealing with the big
melt-downs. A common mistake is to plan only for the latter.

What I do, is as follows:
- C: is 7.99G (4k clusters on FAT32); episodic imaging via BING
- D: is 2G FAT16 (large clusters, easy manual file system repair)
- E: is laaarge FAT32
- F: is 7.99G FAT32

User data is herded into a subtree in D:, while all bulky and risky
(incoming) material is located on E:. An automatic overnight Task
archives the data subtree on D: to volume F:, which is sized so that
the backup subtree can easily be dumped on DVDR(W). The last 5 of
these automatically-generated data backups are retained on F:

Now if there's a little data glitch, it's easy to browse the data
archives in F: and pick out the file to recover. If the C: melts
down, it can be restored from image while leaving other volumes
intact. Something that eats the whole HD forces a rebuild or image
restore, restore of data backup, restore of any large content backups
from E: that may have been done, etc.

I refine this in small LANs by read-sharing the backup location and
having other PCs on the LAN pull and store the most recent data
backups later on each night, as another automatic Task. Once again,
it's easy to pull this accumulated backup set onto DVDR(W).

If a second HD is available, then it makes more sense to store the
auto-backups there - but you still need to hedge against disasters
that impact on the whole PC (theft, fire, lightening, etc.)



>--------------- ----- ---- --- -- - - -
First, the good news: Customer feedback has
been clear and unambiguous.
>--------------- ----- ---- --- -- - - -
.

Quantcast