Hi all,

Looking for some advice from all you knowledgeable Linux folk.

At work we have this six year old Pentium I class computer running a piece of garment design software from a company called "Lectra" on Linux (don't know the version). This computer is dedicated to this one software package and automatically boots into and runs through a custom GUI so you never see a Linux prompt. The computer was originally set up by and is soley administered by Lectra themselves.

Anyway, following a risk assessment we did last week, it turns out the backup tapes we have been making all these years aren't worth the tape they're written on (coz company Lectra who we sent the tapes to for verification say they can't get any data off them,... D'oh). So we are at risk of loosing years worth of patterns if the hard drive in this machine dies (which may surely be imminent due to the age of the drive). We are in the process of upgrading the unit but this may take many weeks / months due to "corporate lag" (like "turbo lag" but longer and infinitely more boring).

Since I am the person most likely to have their world "shat on" if a drive failure occurs, what I would like to know is....
IS THERE A SIMPLE WAY FOR A LINUX NEWBIE TO DO A DRIVE COPY.

I am familiar with PC hardware & windows, but know little about Linux. Can I use partition magic or ghost or ??? - HELP !

Cheers, Sim

Ghost will not work (or at least the versions I know.) Anything that does a bit for bit copy should, in theory, be fine (HDCOPY etc) but be weary. Just to be safe thought I'd at least create a tar ball of the original drive to tape or another drive.

I assume that there's a tape drive on the machine. I'll also assume that it's running the ext2 filesystem (a pretty safe bet if it's been in place for years).

You need to determine the device name of the tape drive. It will be a file in the /dev filesystem. Unfortunately, this is going to be a little hard to determine. Do an ``ls /dev/*mt*'' and see what you get. You probably want the one numbered 0.

Then pop in a tape and run ``mt -f /dev/<device found> status'' and see if you get reasonable looking info. (Replace ``<device found> with the device you found above.) If so:

Run ``tar cf /dev/<device> /''. This will take a long time. Once it's done, run ``mt -f /dev/<device> rewind''. Then run ``tar tf /dev/<device>'' and see if the filles are listed back out.

This is very simple, but it should at least get you a copy of the data onto tape.

There's some reasonably complete information at http://www.storagemountain.com, nee BackupCentral.

Ghost will not work

Ghost 2002 works fine with ext2 filesystems. However, as Bitt says: using tar is the right answer.

CLS / Bitt / Roger, thanks for answering.

OK, I'm with you all on the concept of creating a "tar ball" of the drive onto another device.

Unfortunately I have to assume / suspect the tape drive is toast and would prefer to "tar" onto another medium. Now, as it happens the computer has two hard drives, one with Linux and the other with Windows 3.11 (hmmm), would it be possible to create the tar ball onto the windows (dos) drive instead of the tape?

I assume if I wanted to do this I would first have to find out the identity of the dos drive, then mount the dos drive, then issue the tar command as......

tar cf /dev/<device name of dos drive> /

- Make sense Y/N

Cheers, Sim

Really, using dump would be the right answer, IMHO, but Linux filesystems have rarely had a dump/restore that's up to the task. xfs and its dump/restore seem to be working out pretty well, though.

Many tars have had limitations and bugs that made it a poor choice for this sort of thing, but the gtar that's almost definitely installed under Linux has had these fixed (by using its own proprietary format), assuming it's also what you use to extract the archive. Alternately, you could use a POSIX-compliant tar like star.

Okay. Enough soapboxing.

You'd want to mount the Windows filesystem and then write the tar file onto that filesystem. Something like:

mount -t msdos /dev/<device name of dos drive> /mnt

tar cf /mnt/linux-bk.tar --exclude /mnt /

If you specified the device as the argument to the f option, like you quoted, then you'd overwrite and corrupt the the DOS filesystem.

Also, you need to be careful if the amount of data to be backed up exceeds 2Gb. In this case, pipe the output through GNU split onto the other disk.

Thanks Bitt, that seemed to do it.

Typed in as you said and now filenames are flying across the screen.

Result!!

All I need to do now is wait for it to finish & check the dos drive.

Interstingly, if you're seeing filenames scrolling by (I assume you specified the v option to tar, as well), then the tightest bottleneck for the tar process is likely to be waiting for your display.

If you really want to capture those filenames somewhere, then I'd suggest that you redirect the output to disk by placing a ``> /mnt/linux-bx.txt'' at the end of the tar command line. It might even be worth your while to break out of the current backup (by pressing Ctrl-C, in all probability) and start over with that redirect (or not specifying `v'), depending on how many files you're backing up.

Oh, and make sure you ``umount /mnt'' (or whatever mount point you used) before you reboot the machine, after you're done using it. I don't know how smart Linux is going to be about doing that on its own.

As you summised, I used the verbose switch (because I like watching filenames scrolling quickly ).

Several thousands of petite files took just over five minutes. The "tar" file is residing on the dos drive (checked with "ls" command in the /mnt directory.

Good call on the "umount", almost forgot in my excitment (this ranks up there with upgrading both the empeg & TiVo as one of the Linux highlights in my life. Thank you.