After a day or so of running tests, making boot diskettes and cd's and trying New Things... We finally have a backup solution for networked computers that do not need to be backed up very often.
We boot a system on tomsrtbt - and I created a bootable CD of it as well - and then configure the resulting linux system for the network. I have specific IPs available and authorized to connect to the storage server. Once the networking is correct and we can ping the storage server :
On target server : nc -p {portnumber} -l | dd of=filename.dd bs=4096k
On source machine : dd if=/dev/hda1 bs=4096k | nc {ip of target server} {portnumber}
This gives us about 4mb per 2 seconds, or about 10gb in just over an hour and a half. Of course, this is an image, so it will be the same size as the partition you are backing up... We then have a crontab script that bzip2 compresses the resulting dd files later that night.
Recovery promises to be simple, as long as the target drive is partitioned the same as the original one was.
On the con sides, you can't recover specific files, and you really need that network interface. Otherwise you need to copy the (uncompressed) dd file to some portable media that you can read with a linux system (tomsrtbt). I suppose an external usb drive would work fine if needed.
So:
1. We can use this Linux dd-nc method, where we cannot recover files, but complete system restores are easy.
2. We can use Ghost, where we can recover files and do a complete restore easily, but cannot store the image on the network - we have to store it to a local fat partition and then copy it to the network later if we want it there. I understand that perhaps the newer versions allow you to store the image on a local ntfs partition, and the enterprise $$$ version allows network storage. We would like to avoid that.
3. We can use Windows Backup, where we can recover files if needed, but a complete system restore is iffy.
4. We can use a smbtar method, but that only gets files that are not in use or protected by the OS.
5. We can purchase BrightStor licenses and back them up to the tape library, BUT as we have seen from the problems with the existing w2k server, this method is not exactly optimum. It generates a large percentage of errors on the w2k's port on the switch, and can result in network denial from massive numbers of port reconnections.
I'm leaning towards a combination of 1 and 3 - so we have file by file restore for most files, and a good system image to fall back on. We might supplement this with ghost - need to research it more first.
