At 08:03 2002-03-27 +1000, Tony Nugent did say: >I have an NT box on a LAN working as a file and application server. >There is a linux/samba server that does just about all of the >network services for a bunch of windows clients, the linux box also >has a 12/24Gb scsi2 tape drive in it.
>Backing up the files is it storing is easy, that can be done over >samba shares (and at night when no one else is using any of it). There's always a fine argument for putting data and applications on a separate HD from the base OS... >Backing up the os (ie, C: drive) is problematic on a running NT >system, expecially with file locks not allowing access to things >like the registry and in-use dll and db files. Yup, but then, in-use db files are an issue on most OS' anyway, and you can figure the registry is sort of a db file. I'm not aware of _exclusive_read_ locking on DLL files though - you should be able to read them, just not change (or delete) them. > And worse, the >result has no hope of being put back onto a hard drive to boot and >work successfully as if nothing had happened. Your best option for a recoverable NT backup is to image the partition. I personally use Ghost for a base OS backup (that image would give me a bootable and hardware-compatible OS install back on the HD), then use an NT-based file backup solution for the regular backups while the system is running. >What I have done so far is to (manually) reboot into tomsrtbt and >dump the (static) contents of raw ntfs partition device files over >the network onto the tape drive using either bzip2|netcat or dd. Which is what I'd do if I were to attempt to be doing things the way you are. >a "clean" dump that can be put back, and it will work. I assume that you have actually taken a spare HD and tested the restore procedure (clear through to booting the machine from it)? This is a MUST. >Assuming boot from a rtbt-floppy, the boot sector on it would need >to be changed ** by something running under NT ** just before the >shutdown to boot into the tomstrbt backup. See if you can't get NT to reboot in "warmboot" or "coldboot" mode, and tomsrtbt to do the opposite. Then, hack LILO to check to see which boot method was used. The word at 0x40:72 contains the boot mode. From memory, it is 0x0000 if it was a cold boot (power cycle, reset switch, or a software-induced reset which explicitly reset the flag to make it appear to be a cold boot), 0x1234 is a warm boot (skips memory check, but memory might be whacked just the same), and 0x4321 is a warm boot wherein memory should be left unchanged (though I've never presumed it to work reliably, with all the different BIOS'es out there. If you set it up so that NT warmboots, then when the system is coldbooted (say, someone is standing at the console and hard resetting it, or if the power tripps unexpectedly), then it'll load into NT automatically (because LILO would say "coldboot, oh, tomsrtbt just induced the reboot, so we're heading into NT"). OTOH, if you did it the opposite, then under those conditions, tomsrtbt would load up and try to run a backup - quite possibly when you don't want it to (say, because the HD is fried). This could be used to your benfit though -- you could have your backup script check the time and presume that any reboot outside of the general timeframe of the scheduled backup is cause for alarm - with some scripting tomsrtbt could be used to signal an alarm and be sitting at the ready for a remote session to run badblocks on the HD or spool up a restore. Presuming that the system doesn't halt and wait for keyboard input in the event of an HD error during boot... If you hack the LILO code to check the boot mode, then no writes need to occur on the floppy, and it can be write protected (which is a GoodThing(tm)). No, I haven't done this, but if I were trying to accomplish what you are, this is how I'd go about doing it - then again, I've written boot loaders in the past (though not worked on LILO myself) and write in assembler. A simpler alternative might be to write program in NT that can update the CMOS - changing the BIOS to boot to floppy before HD, and having a similar program on the TomsRTBT diskette which changes the value back. There's a checksum to contend with computing, but it isn't rocket science. The specific settings should be easy enough to empirically determine if you can dump the raw content of the CMOS. It'd probably be easier to write a Windows or dos program to do this, and when you have the system set the A-C or whatever, simply remove the floppy so that it still boots into Windows, and you can dump it just as if it had been set to C-A. Also, if your script on TomsRTBT checks the current CMOS value before proceeding to run a backup, it could self-determine if the HD failed to boot (if the CMOS is currently set to C-A, and you still managed to boot off of the floppy, what does that say?) and take steps to alert someone. >It is possible to get a complete backup of an NT box using the >ntfs.o modules to backup the actual files on the filesystem (ie, >using either backup or tar). (I haven't actually tried the tomsrtbt >ntfs.o module, I assume that it works ok:) I'm with Tom on this - don't use NTFS capabilities of Linux and expect them to work reliably. Stick with dumping the raw partition. >In the end I would much prefer not to backup the raw partitions as >this does not give easy access to any of the files within it. Bummer. Perhaps you should consider installing NT on a FAT partition? Yes, you lose certain security (and other filesystem) features. If it is a server without console access for users though, most of the primary needs for NTFS are out the window (disk space optimization and directory integrity are probably the two biggest generic features you'll lose in switching to FAT). FTR, beware if you get into W2K and its "Dynamic" partitioning. With my schedule, I sure am glad this is your problem - looks like you have a couple of days of work cut out for you. --- Please DO NOT carbon me on list replies. I'll get my copy from the list. Sean B. Straw / Professional Software Engineering Post Box 2395 / San Rafael, CA 94912-2395
