Re: Gentoo on Sun Ultra 5

On Thu, 27 Oct 2005, Chris Croughton stipulated:
> On Wed, 26 Oct 2005 11:30:21 +0100, Nix
> <nix-razor-pit@xxxxxxxxxxxxx> wrote:
>
>> On Sun, 23 Oct 2005, Chris Croughton spake:
[backups]
>> Do you really change your mail spool and data you worked on last year
>> but which might be useful later *that* often? :)
>
> Have you ever tried restoring from incremental backups when there are
> more than a couple since the last full backup? Especially since most
> backup software doesn't handle moves, renames (and even deletions) well.

Yes. My standard backup system involves a single level-0 backup on CD-R
and incremental backups on top of it on CD-RW until I run out of CD-RWs,
following which an incremental gets added to CD-R instead, based on
the last one written to CD-R.

(All these CDs get copied to reduce the chances of a bad backup disk
torpedoing things.)

(I plan to mix in tower-of-Hanoi backup-generation stuff too, but that
kind of assumes you can erase old backups, which I can't as they're on
CD-R.)


Oh, and your backup software needs replacing if it can't handle moves,
renames, deletions, and hard links properly. (The one I use, dar, is
mildly dysfunctional in the presence of very large numbers of hard links
to a single file and has *insane* virtual memory requirements, but
it certainly handles moves, renames and deletions. The key is simple:
index by inum, just like the filesystem does.)

> I don't even want to think about trying to restore from a 10 year old
> full backup and all of the incremental backups since.

I had to restore a four-year-old backup the other day. This involved one
level-0 backup, two large incrementals on CD-R atop that, and eight
recent incrementals on CD-RW. It was all scripted so all I had to do was
swap disks. (Of course dar has a tool that can tell you what incremental
backup the latest version of some file is on. Of course that tool is
extremely memory-hungry as well. I really must pick dar apart and find
out why it eats so much memory, and stop it. Eating 1.5Gb of virtual
memory to back up a couple of million files is going over the top.)

> Doing rsync once a day over the whole disk takes a bit of time, but at

Make that a *lot*, if you have a lot of storage or a very large number
of files.

> least it has the effect of being a full backup (modulo any files which
> were changing at the time, but that's true of all backup systems).

Er, not my backup scripts. The first thing they do is LVM-snapshot all
the LVM partitions, and mount or mount --bind everything into a separate
tree. Then *that* is backed up.

Obviously if / is changing they'll still be in trouble, but that's 'cos
I don't snapshot / because it's not on LVM. Snapshotting using
device-mapper is possible but so annoying I haven't done it yet:
<https://www.redhat.com/archives/dm-devel/2004-July/msg00071.html>.
(The biggest problem is that I'd have to make / a device-mapper-managed
device, which brings the whole initrd/initramfs mess into play again. The
only advantage is that you'd still be able to access / even if your
initrd failed...)

>>> And even 100 DVDs is only 470GB, a sixth of the storage on my
>>> Win2k 'media' machine, and takes up a lot more space than a couple of
>>> USB2 250GB drives...
>>
>> Well, yeah, the media stuff is also relatively incompressible so it'll
>> eat a lot of space. But then we knew that; there's a reason why you need
>> a whole CD to store, well, a CD's-worth of music, for instance :)
>
> Yup. And a whole hard disk to store a hard disk's worth.

.... or a big pile of CDs in the loft. :)

>>> I use reiserfs on my fileserver
>>
>> *shudder* rather you than me. From all I've seen the reiserfs guys have
>> made entirely too many dumb design errors to be trusted with my
>> significant data. (The oops-we-can't-distinguish-between-data-and-
>> metadata idiocy in reiserfs 3's fsck was only the most *notable*.)
>
> It was the recommended choice at the time (everyone was saying that ext3
> was obsolete).

The reiserfs crew (OK, Hans Reiser) made extravagant promises, and we
believed them. The promises were sort of true: reiserfs really *is*
faster than ext[23], and really *is* more space-efficient; alas it's
faster only under some workloads, and those workloads aren't very
common, and it's more space-efficient only if you turn on tail packing,
which kills performance.

Oops.

> Now it's swung back. But with daily sync of an ext3
> partition to it there isn't much that can change.

True enough.

>> reiserfs is in use for my news spool and wwwoffle cache: i.e., stuff
>> which can be restored easily or is relatively unimportant when (not if)
>> reiserfs blows up again.
>
> Actually, my news spool can't be easily regenerated, not past about a
> month old.

Ah, true, if I lost bofh.* it'd be amusing; I don't expire that
hierarchy. But that's why I back it up. (Yes, I back up part of my news
spool. They call me demented, but they are wrong, hahaaaa, *wrong*...)

>> I used to be the same, but I've found myself using xfs more and more.
>> It's nifty. (Look out, though: Tim Haynes used xfs and we've not seen
>> him on this group for months: the implication is that the filesystem
>> ate him).
>
> Hmm, I still think of xfs as 'experimental'...

What? It's older than ext2! (Not on Linux, admittedly, but a large part
of the codebase is shared.)

>> (You still run 2.2? Wow, and I thought I was a stick-in-the-mud ;) )
>
> On a couple of machines (including this one). It's a big pain to
> upgrade, with the dev/devfs/whatever changes.

Let's see, what major pains did I have...

2.2 -> 2.4: ipchains -> iptables. Ameliorated by the ipchains module
for iptables, but rewriting the fw rules was a good idea
anyway. Possibly other stuff but I've forgotten it.

procmeter needed patching for a buffer-overrun bug triggered
by the new format of /proc/stat (I think it was). (But this
patch went upstream so nobody else needs to bother.)

2.4 -> 2.6: LVM1 -> LVM2. The on-disk formats are backwardly compatible
unless you're unlucky enough to use lvm-2.01.12 (which
broke the lvm1 metadata reader by mistake), but the userspace
tool initialization is different enough that it took a good
bit of cursing before everything was up again.

devfs -> udev. I never used devfs because I hated its design
so for me this was just a matter of installing udev. It would
take prolonged torture to make me go back: udev is
*wonderful*.

Weird SPARC64 problems. I first switched to 2.6.10, which
had a SPARC64 lock atomicity bug such that it would effectively
never swap (well, not unless you had nearly 2^64 bytes of
physical RAM, which oddly enough I don't). Dave Miller fixed
it in hours. There were lots of nasty UML bugs that torpedoed
my every attempt to keep my firewall upgraded for weeks.

procmeter needed patching again to handle device-mapper-backed
disks and the new 64-bit context-switching fields in /proc/stat.
(This patch went upstream, too.)

But in general it was a trouble-free upgrade, and 2.6.x is so much nicer
than 2.4.x (performance-wise and feature-wise; I'm thinking of digsig
and SELinux and udev and device-mapper and NPTL support in particular
here) that there's no way I'm going back unless Linus goes insane and
rewrites the kernel in Visual Basic (and he's promised that if he
does that he'll call it version 3.0).

> I tried, the resulting
> mess was so unstable that I reverted to a stable version. When I ever
> rebuild this machine it will be Gentoo rather than Debian and so will be
> a 2.6 (or later) kernel.

Well, Debian has well-working udev now; I think the initrd also supports
udev. (Debian mkinitrd was devfs-dependent for a *long* time, but I
think this has been fixed.)

>>> Oh, I do that anyway (two 120GB drives, I should upgrade those
>>> sometime). Called, unimaginatively, /export/home1 and /export/home2.
>>
>> I dunno, I've only got one drive that large myself :)
>
> 2x 160GB on my backup machine.

Unfortunately I spent all the money I had and all the money I didn't
have on one of those house things so I can't afford decently-sized disks
right now. So expensive and yet it's not scriptable at *all*, it's
disgraceful.

>>> Probably. Since my idea of a database is an ASCII file that I can
>>> process with awk
>>
>> Most of mine are like that, too, but there are a few for which
>> high-speed joins and bisections really mattered, so I used PostgreSQL
>> for those, and they just grew. :)
>
> I'm not a database version, I have little idea of what "joins and
> bisections" are <g>. I can guess at the first, the second sounds
> painful...

Heaps of WHEREs, basically. If you've got lots of data, repeated greps
get a bit slow...

(I'm not a database version either. :) )

>> cp -al is your friend in any case; it significantly reduces the space
>> used by similar trees. (svn cvs and patch all take care to unlink() at
>> appropriate times, so you've got little danger of overwrites as long
>> as your text editor acts similarly.)
>
> I generally just get the tarball so it's all 'new' files.

It's a lot faster to cvs update (well, svn update as of the end of
this weekend, thanks to Dan Berlin :))) )

> And it's the
> object files -- which /are/ all different --

They'd better not be unless you want your build to fail with a bootstrap
comparison failure :)

Look up `make bootstrap-lean', which deletes the unnecessary object
files. Generally the only time I use `make bootstrap' is when I'm
debugging a bootstrap comparison failure...

> which take up most of the
> space, because gcc builds itself several times (3 or 4, I lose count).

Three times unless the target has obscure bugs (I`m not sure if anything
needs bootstrap4 anymore, it used to be only certain old HP-UX and AIX
bootstraps that did).

> Unfortunately, where all too many applications are concerned it is still
> true for the ordinary user (and where things using graphics are concerned
> I'm a 'user' --

Likewise, and while I'm trying to correct that with some desultory KDE
hacking I'm afraid Wesnoth and oolite are stealing all my time. :)

> heck, it's 20 years since I last wrote a text editor or
> even looked inside one, these days I use vim on every platform).

So do I --- for quick edits when I'm already at a shell prompt. I can't
remember any significant vi keys; they drop straight out of my memory
and are replaced with the mantra `just use emacs'...

> Linypond is
> still nowhere near the usability for the ordinary user (if one can call
> musicians 'ordinary' <g>) that is needed.

Reluctantly agreed: like TeX it's still a backend for other things that
want nice typesetting to talk to.

> Of course, nuking the partition table will work on virtually any drive
> no matter what the filesystems...

I'm not sure if a RAIDed disk is vulnerable to that (assuming you only
nuke one copy).

>>> Hmm, it was some *ix system, I don't remember which. Effectively like
>>> Linux swap files but they shrank and expanded as needed
>>
>> Oh, right, that's *very* different. You could do it on Linux with an
>> mlock()ed realtime-priority daemon that watched /proc/swaps and
>> mkswapped more swapfiles as needed; it's been discussed on l-k but I
>> don't think anyone's ever done it. (The DoS potential is... high.)
>
> You'd need it to come in when memory was needed (i.e. on the request).
> Shrinking can be done with a daemon, it's less critical.

I think you could do it as long as the daemon was mlock()ed and
sufficiently high priority (i.e. realtime): it would probably also need
a hook in the kernel that chattered to it (over a netlink socket?) when
swap was exhausted. Any looping bugs in the daemon would be lethal, of
course.

>> Swap-over-NFS? That's *hard* without deadlocks. Hell, even block I/O
>> over the network is hard to do without deadlocks: witness the deadlock
>> potential in NFS, NBD and the iSCSI layer now causing intermittent
>> flamewars on l-k...
>
> Yes, swap over NFS is pretty silly anyway, far too much can go wrong.

It's coming; if you want to swap to iSCSI or a NAS, you need to swap
to an NBD at least...

--- and the deadlock-proneness is true of *all* file writes (well,
writes triggered by a shared mmap(), really) on any networked
filesystem. Imagine filling up memory with dirtied mmap()ed pages:
now where do the incoming packets get stored that are needed to
flush those pages?

(This *is* fixable by discarding all packets on that network device
which don't directly pertain to the I/O in progress when very short of
memory, and fixes are ongoing. But it's tricky to fix.)

>>> In most of my machines it only uses real memory anyway. I don't want it
>>> swapping out things that I want to use (code and data) just because
>>> something writes a large temporary file.
>>
>> If it's temporary-as-in-soon-needed, this was the right decision. If
>> it's vast it's likely *it* will land in swap instead...
>
> If it's needed soon enough it will go into cache (and swapping disk
> cache memory is another silly thing, I hope no modern systems do it!).

That's a meaningless statement where Linux is concerned. Dirty anonymous
and private file-backed pages get swapped when under pressure, others
get flushed back to file (if dirty) or discarded (if clean). Pages can
easily be in swap and in memory at the same time: after all, why discard
a swap page just 'cos you swapped it back in? If you leave it on swap
you can now simply discard the in-memory page if memory pressure goes
back up again.

There's no point swapping buffer cache pages (containing metadata): they
just get flushed.

> However, things which write a 1GB file in /tmp should put it on disk,
> not push everything else out of memory...

What if you're writing it only to read it back in again?

user-mode-linux represents its guest's memory as an mmap()ed file of the
appropriate size in /tmp. Ideally this should be treated as just like
RAM --- and it is (modulo some inefficiencies with regard to sharing of
page caches between host and guest which are still being fixed). You
certainly wouldn't want to force it all to disk.

>> Another fun one is gtk-qt, which is a very nice engine if you have a
>> nice Qt theme and want to make your Gtk apps look similar... but the
>> last released version has a huge memory leak that eats ~5Mb/min in the X
>> server. (The copy in CVS HEAD is reliable, but not released...)
>
> Ouch. Opera tends to run away with both memory and CPU sometimes (if I
> look at the load -- I have xload on the desktol -- and it's sitting at
> over 1 for a long time I suspect Opera).

Hm, that's an interesting question: what do people use for real-time
monitoring? I imagine most people have something like an xload running
so that they can see if something lunatic suddenly starts running away
with the machine...

I went perhaps a bit over the top with procmeter. I have these on the
desktop:

procmeter3 -geometry 100x704+1166+109 -name ProcRightmost Statistics.CPU_User-g Statistics.CPU_User-t Statistics.CPU_System-g Statistics.CPU_System-t Processes.Load-g Processes.Load-t Processes.Forks-g Processes.Forks-t Statistics.Context-g Statistics.Context-t Statistics.Interrupts-g Statistics.Interrupts-t VM_Statistics.Page-g VM_Statistics.Page-t VM_Statistics.Swap-g VM_Statistics.Swap-t Stat-Disk.Disk-g Stat-Disk.Disk-t Date_Time.Uptime_DHM Network.Pkt_Rx_gordianet-g Network.Pkt_Rx_gordianet-t Network.Pkt_Tx_gordianet-g Network.Pkt_Tx_gordianet-t ProcMeter.Version

ssh -n -x amaterasu procmeter3 -name ProcGlobal -geometry 100x643+1056+111 Statistics.CPU_User-g Statistics.CPU_User-t Statistics.CPU_System-g Statistics.CPU_System-t Processes.Load-g Processes.Load-t Processes.Forks-g Processes.Forks-t Statistics.Context-g Statistics.Context-t Statistics.Interrupts-g Statistics.Interrupts-t VM_Statistics.Page-g VM_Statistics.Page-t VM_Statistics.Swap-g VM_Statistics.Swap-t Stat-Disk.Disk-g Stat-Disk.Disk-t Date_Time.Uptime_DHM Network.Pkt_eth1-g Network.Pkt_eth1-t ProcMeter.Version

ssh -n -x loki procmeter3 -geometry 100x803+$(($[vp.width]+946))+$(($[vp.height]+111)) Statistics.CPU_User-g Statistics.CPU_User-t Statistics.CPU_System-g Statistics.CPU_System-t Processes.Load-g Processes.Load-t Processes.Forks-g Processes.Forks-t Statistics.Context-g Statistics.Context-t Statistics.Interrupts-g Statistics.Interrupts-t VM_Statistics.Page-g VM_Statistics.Page-t VM_Statistics.Swap-g VM_Statistics.Swap-t Stat-Disk.Disk-g Stat-Disk.Disk-t Date_Time.Uptime_DHM Network.Pkt_gordianet-g Network.Pkt_gordianet-t Network.Pkt_Rx_adsl-phys-g Network.Pkt_Rx_adsl-phys-t Network.Byte_Rx_adsl-phys-t Network.Pkt_Tx_adsl-phys-g Network.Pkt_Tx_adsl-phys-t Network.Byte_Tx_adsl-phys-t ProcMeter.Version

The first of these is for my desktop box and hugs the right hand side of
the screen; maximized windows avoid it. Next to it is the procmeter
monitoring my headless Sun: it floats on top of maximized windows and
can be buried beneath them with one keystroke. The last is the firewall
virtual-machine host; that one doesn't follow me around but sits on a
single virtual desktop.

>> ssh wants xauth if you want to keep X connection forwarding working.
>
> It's only recently that I've had X forwarding on at all. Virtually
> everything I want to do on a remote machine is text/console based.

That used to be true of me, but these days I can pretty much ignore what
host I'm on when running X apps unless it's something like a full-screen
xine. This is ideal in my view :)

>> Nah: if you start KDE like this:
>>
>> KDEWM=/usr/bin/fvwm2 startkde
>>
>> then you get a full session-managed KDE desktop with the window manager
>> used being fvwm. If you use fvwm-2.5.12+, the only bit of KDE which
>> doesn't work as a result is the bit of the control center which controls
>> kdewm (not even remotely surprising, that).
>
> Ah. But then you get the big KDE desktop.

Well, yes. If you don't want it you don't run startkde. I wanted it,
given that I wanted session-management and I was killing rxvt and moving
to konsole, but I wanted fvwm too. :)

>> and then I can have a set of procmeters started with the -name option,
>> some of which obscure the rightmost part of maximized windows by
>> default, but upon one keystroke (bound to BegoneProcmeter) they sink out
>> of sight, to be restored with another keystroke; the panel obscures them
>> at all times. Maximized windows stay out of the way of the rightmost
>> procmeter (started with -name ProcRightmost), which gives info on the
>> local machine.
>>
>> (Layers are a *very* nice idea.)
>
> Hmm. In general I don't like things 'hidden', I'd rather just have them
> on another desktop.

The point about the hiding is that it's *one keystroke* to see them
again: and they're a thin bar to the right hand side of the screen,
which side is underutilized anyway. I normally have that procmeter
visible unless I'm using some graphical wossname (or playing wesnoth or
oolite, of course ;) )

>> #!/bin/sh
>> #
>> # kssh --- Helper SSH invoker for KDE session manager
>> #
>>
>> exec ssh -f "$@"
>
> Ah. I do 'interesting' things with ssh to force environment variables
> through to make sure thatthey are properly set.

e.g.

PermitUserEnvironment yes
AcceptEnv DISPLAY X_ORIGINATING_HOST

et al? I'll admit I do peculiar things there, in particular with the
DISPLAY environment variable.

I had enough of messing with DISPLAY long ago, and ssh-encrypting X
traffic sounds all very well until you have a lot of it and some of your
machines are slow, so I have an ugly hack to automate everything. My
..Xinitrc sets an environment variable to indicate what machine the
server is *really* running on:

export X_ORIGINATING_HOST="$(hostname)"

and they get allowed through by ssh_config as well as sshd_config:

Host *.nix [...]
Compression no
ForwardX11 no
ForwardX11Trusted yes
SendEnv DISPLAY X_ORIGINATING_HOST

and then I have a hack in my /etc/envrc that uses those variables:

# If we are on a host remote to our initial X display but our DISPLAY
# does not reflect that, fix it up.
case $DISPLAY in
:*) [[ "$HOSTNAME" != "$X_ORIGINATING_HOST" ]] && DISPLAY="$X_ORIGINATING_HOST"$DISPLAY;;
esac

This means that on the local net (which I assume is reasonably secure,
after all I run NFS over it so it had better be), I can do `ssh blah'
and get an un-SSH-tunnelled X connection, or `ssh -X blah' and get an
ssh-tunneled connection: the latter is still useful for sshing to
different users on different hosts and keeping your X connection, and of
course for doing Nasty Things without the theoretical person sitting
across the room noticing with his ethernet tap. (What? He can still look
over my shoulder? That's a purely academic attack. No gentleman would do
that.)

Combine that with

session optional pam_xauth.so

in /etc/pam.d/su, and my X cookies follow me everywhere I trust the
security of and then vanish like mist when I move outside the local net.

>> I'll admit to using links -g quite a lot (the font it uses is lovely),
>> and emacs-w3m for most of the rest of the non-cartoony stuff. (Not
>> Dilbert, though, I get enough of that at work: Schlock Mercenary. :) )
>
> Actually, I usually only read Dilbert at work in lunchtimes Talking of
> lunchtime...

What a good idea.

[pause]

> And I do choose to install none of it <g>. (In fact when some package
> manager 'helpfully' installs it for me -- thank you dselect! -- I have a
> tendency to do find / -iname '*emacs*' -exec rm {} \; (as root).)

That's a very dangerous command to run, as well as a very slow one. Why
not just, um, aptitude purge? rm'ing things behind the package manager's
back is not safe, and assuming that everything containing the string
`emacs' is part of Emacs is really risky.

On this system that command would zap parts of a2ps, autoconf, the
desktop-file-utils, gnome-desktop, guile, kbd, kdeartwork, kdebase,
lyx, octave, and the unified GNOME/KDE MIME database as well as
smashing a considerable number of source trees and rendering them
unbuildable. (In addition to vapourizing emacs, xemacs, emacs-w3m,
emacs-cl and so forth, of course.)

>> That's true, when compiled with debugging that comes to 25Mb, and if you
>> include the huge precompiled headers that adds another 40Mb or so.
>> (Myself, I've never found a use for a set of pre-precompiled headers
>> that includes a random subset of libstdc++, so I just delete those
>> monsters.)
>
> Indeed. It's worse since they made the libc++ properly ISO compliant.

Well, actually the major bloat is the precompiled headers and the fact
that we don't do anywhere near as much compressing of DWARF2 debug info
as we might, and as C++ has huge symbol names thanks to mangling...
the switch from stabs to DWARF2 debug info on Linux greatly increased
the size of debug-enabled binaries (although not their efficiency at
runtime as the .debug* sections are not LOADable).

>> I posted about it instead. (Call me an old-schoolist, but I greatly
>> dislike HTML and all that jazz.)
>
> I wrote a page the other day. It has two images on it and a bit of
> text, and took me about 2 minutes (half of which was looking up the
> format of the <img> tag!).

That I can cope with. But `web applications', well, I write them at
work and, well, ick. Talk about an abuse of a medium.

[util-linux mount hack]
>>> Heh. And goodness knows how long it would take to get into distros.
>>
>> A couple of years seems to be typical for near-complete coverage ---
>> although it would probably hit some within days.
>
> And Debian would accept it about 3 years later...

Almost immediately actually :) it'd take years to hit *stable*, sure...

>>>> I think that's about the highest of the AMDs that'll run fanless, too.
>>> It will, although a hot summer day will knock it out if it's fanless.
>> That's running very close to the edge!
>
> Yup. I had one where the fan got stopped (a wire got into it), the chip
> ran happily for a week or so and then crashed.

You're lucky that's all that happened to you.

I had a CPU fan failure and got a few emergency thermal shutdowns but
otherwise only noticed when the burning smell started. The insulation
on some of the power cables was melting...

(I got lm-sensors working *sharpish* after that.)

>>> I've never run links with graphics support seriously (I did it once just
>>> to se what it was like).
>>
>> links-2.1pre* is the only version with decent graphics; it's pretty
>> nice, and probably displays graphics on more platforms than any other
>> non-mobile-capable web browser (Opera probably beats it on that front).
>
> Hmm. How's it's Javascript these days? Last time I tried it seemed to
> barf on most sites.

It still *moans* on most sites, but the sites work. (at least the
ugly-but-necessary things like JS links work.)

Still no cookies, by design, which is really annoying as it means I can't
read LWN up there without resorting to horrid lynx.

>> (It also would probably eliminate my desk: we had to take the door off
>> its hinges to get it in the room...)
>
> My things have to go up stairs and round corners as well.

There's a reason why my desktop box, and desk, are on the ground floor
;) we had to fit that desk up a flight of stairs with two bends in it
once: it took hours.

> Have I mentioned that I hate DEC AlphaStations? They bite. Yesterday
> one bit my arm when I was unpacking it,

All computers do that. They don't work properly unless they get their
blood.

> and then tripped me at the top
> of the stairs when I was carrying it.

But *that* is either malicious or suicidal.

--
`"Gun-wielding recluse gunned down by local police" isn't the epitaph
I want. I am hoping for "Witnesses reported the sound up to two hundred
kilometers away" or "Last body part finally located".' --- James Nicoll
.

Relevant Pages

  • >>> DISK BACKUP <<<
    ... disk to disk backup ... backup ps2 hard disk ... disk to disk backup software ...
    (rec.music.hip-hop)
  • Re: Folder security. FAT to ntfs?
    ... it is recommended you backup your critical ... a clean system BEFORE you start.. ... What to Know Before You Download and Install Windows XP Service Pack 2 ... application, Disk copier, etc.) You'll be glad to know that if you have ...
    (microsoft.public.windowsxp.general)
  • Re: Replacing Notebook Hard Drive
    ... both the disk cloning & disk imaging capabilities of the ATI program. ... Step-by-Step Instructions for Using the Acronis True Image Program to Backup ... can take to back up the entire contents of one's day-to-day working HDD, ... With both hard drives connected, ...
    (microsoft.public.windowsxp.hardware)
  • Re: Replacing Notebook Hard Drive
    ... both the disk cloning & disk imaging capabilities of the ATI program. ... Step-by-Step Instructions for Using the Acronis True Image Program to Backup ... can take to back up the entire contents of one's day-to-day working HDD, ... With both hard drives connected, ...
    (microsoft.public.windowsxp.hardware)
  • Re: Acronis and new disk
    ... with using the disk copying/disk cloning programs such as the MaxBlast ... contents of your 40 GB HDD to your new 120 GB HDD rather than creating a ... Step-by-Step Instructions for Using the Acronis True Image Program to Backup ... With both hard drives connected, ...
    (microsoft.public.windowsxp.hardware)
Loading