I have FreeBSD 6.0-RELEASE on a P166. While that isn't my main box, it's still worth backing up.

It does have a CD-ROM drive, and I'm reluctant to spend money on a CD-RW drive for a P166. So I got interested in Amanda so I can store the backup on my Linux system. It has enough hard drive space to hold the latest backup, and (with compression) one single-layer DVD might be able to hold the entire P166's 10 gig hard drive.

The only problem now is how I would restore if FreeBSD became totally trashed or if the hard drive kicked the bit bucket. Can this be done across the LAN? Making it more complicated, the P166 can boot only from hd and floppy (though I can switch to CD after starting a floppy). I already tried software solutions like sbm and it can't be done. Only converting to all-SCSI (too expen$ive to consider) would let me boot a CD.

If Amanda isn't the right way for me, then what might be? I do have USB 1.1, so I could get a hard drive big enough to backup both systems -- though USB 1.1 would be painfully slow.

Make ready-to-boot HDD you can always attach on failed machine. This way you'll be able to rewire your IDE's, boot from ready system and fix anything you want.

I am not familiar with the particulars with Amanda but it looks similar to what I do -- which is a network dump(8) to another machine of important information (it's compressed as part of the dump by going through a gzip filter). As long as you stick with the familiar tools (dump, ssh, gzip) you'll have no problem restoring over the network. You should be familiar with how these work but it's not too complicated. I've had to do a complete restore of my router before (NetBSD but the priciple is the same) after the hard-drive went and it was a breeze. Just boot from the floppies, mount the live restore CD, and you're on your way.

I had a peek at the FreeBSD Handbook. It looks like dump via ssh would also work for me. I presume dump would only dump what's actually used and not the free space with it?

FreeBSD has no live CD as far as I know of. Would another BSD's live CD do? And how would I handle the MBR and such to make the replacement hard drive bootable?

Your assumption is correct here. The dump space used depends on how full the file system is, as well as how much has changed since the last dump of an equal or lower level (if you're doing incremental dumps -- which I recommend because a level 0 dump done daily will take a massive amount of time depending on the size of the disk and the network, once a week is not bad but daily and it will eventually drive you nuts).

Disk2 is a live recovery CD. And, the first disk has the vast majority of the tools you would need as well. So you could use that in such a situation that you don't have disk2. As for making the drive bootable, the easy way is to use the sysinstall program to partition the disk and prepare it. If you need to do it by hand, become familiar with the boot0cfg(8) man page and all the pages it references.

I've done this very thing just recently. It does work.

I *strongly* suggest that you practice a restore once or twice though, and take notes. If you can get rdump into interactive mode, and list the files you backed up, you probably don't have to actually do the restore.

IRRC, I had a few issues getting the network up and running so I could access the remote system where the tape|disk drive has the dump file. So you are better off walking through it once or twice before you really need it.

There may have been an issue getting the slices setup on the disk just the way I needed to. This is from memory at the moment. The live CD (and disk 1) didn't have the entries needed in /dev. (That, or I'm just a device driver developer who doesn't know enough sysadmin to do it properly.) I simply moved MAKEDEV.sh to /dev and was able to do what I needed (this was on 4.10, 5.x and later may not need this anymore.)

I have a questions regarding this issue, would the same process work from a FBSD machine dumping the contents of a Windows Server FileSystem? it would be great if it does.

dump and restore are unix utilities. I assume you would install them under cygwin (or something similar) on a Windows machine and they could work. But to be honest, as it is suggested, this wouldn't work well with a windows machine. The restore methods and everything tend to depend on things you can't rely on with windows.

You could always use dd over the network and dump the disk image... but then you would still need some unix utilities to perform the dump and a unix live cd to perform the recovery.

Hi there...

At least for that part of booting from CD on old PC's, there might be an easy fix...

Slackware Linux carries a cool tool for this purpose, it's called 'sbootmgr' and will produce a 1.44 floppy (either using rawrite on win or dd on *nix) that'll boot the PC and present you with a menu with several devices to boot from, including CD-ROM, which I think has it's own boot code and does not rely on the BIOS to do it.
You can find it here ftp://ftp.telepac.pt/pub/slackware/s...linux/sbootmgr
or at any other Slackware mirror.

Cheers

Hi Guys,

I have been reading everyone's post regarding dumping to a USB drive and I was just curious about compatability. My brother bought us one, but when looking at the box, it indicated that it was only good for Winblows OS. Can FreeBSD still detect this device and be able to mount it without using their Winblows software?

Thanks in advance for any commentary about this.

Maybe. The only sure way to know is to try it. Most (but probably not all) usb drives are recognized by FreeBSD because they have a standard interface. The issue is more likely to be with the formatting (ntfs is a pain in the butt to work with) but that can be worked around and if you're not going to use it for Windows you can format it with ufs and use it like a normal bsd drive.

Thanks for the reply.

My only real issue with trying it, is that if it cannot work then my brother is out whatever money he spent on it...(albeit, he should have consulted with me before the spending, I know. )

The drive was intended to specifically be used for this purpose, so it will, fortunately, never see the living virus know as windows...thank the gods for that. As far as what you'd said about formatting, will ufs be able to accomidate a BSD dump file structure?

Well, you have two options. You could dump the file right to the disk. I don't recommend this for many reasons. Part of them being that you've just made the whole thing a single use affair. Can't even put a file of notes on the thing regarding how to restore.

Or you could save the dump as a file on a filesystem. Almost any filesystem will do for that (as long as the GENERIC kernel can read it). The plus side of this is you can keep more than one dump and/or important files to help you restore correctly. Just make sure you use the -f flag and point it at a filename on the drive (it will create the file if it doesn't exist so don't worry about that).

There are many decisions to make when backing up a system. Many are tradeoffs. You can choose to compress the dump (with gzip or whatever) to save space on the device... if it's close to full... and to speed up the transfer to and from the disk. But that can complicate using restore interactively... which makes bringing back one or two files much harder. So there's space and time over ease of use tradeoffs... and other things to consider. But you don't need to worry about them to just get a straight backup. And you may not need to consider these things -- ever. But most people eventually find that some resource is being tapped and will try and reduce it. ... Wow, I digress... I think my point was that you don't need to worry about the format of the dump (as long as you know how it was created so you know how to restore from it).

Edit: You can't return the drive if it doesn't work? Almost all places I have dealt with have said that bringing it back within some short period of time was acceptable if it wasn't going to work with my system. In rare cases you may face a restocking fee... but often you shouldn't even have to deal with that.

Ok...well, that seems a fair explaination then and I thank you very much for your patience with my noobishness.

I have a new problem though that arose as a result of actually trying the unit. When I plugged it in to either server, it detects it as a umass device, but never assigns it to a dev such as daX.

Would you or anyone else happen to know why this would be happening, because it's preventing me from being able to mount it at all. The unit is formatted with NTFS. Should it maybe be FAT32 instead?

This is really beginning to give me a headache, but it's one heck of a learning experience also.

Thanks again for your previous help and any further assistance you may add hereinafter also.

--Adrian