Let me start by saying I know there are packages to do much if not all of this already.
Concise statement of a non-trivial larger concept is to have a Linux server make timed backups of several windows systems in a zero user interaction format- and be able to remote restore those boxes equally "no user assist" required.
Expanding the short concept as :
Backups being BOTH data AND drivers etc.
Restore as being from a file up to a drive wipe and reload using some image system.
The simple explanation is to make supporting windows boxes a bit less painful.
The expanded explanation is as "life support" while beginning a migration to Linux. The reason is that having such a system in place also becomes a pre-migration tool. Imagine doing a ms to LNX migrate where the majority of system users would already have server resident current recently checked backups before you arrive onsite? This is one way to make that possible.
OR the much more mundane target of being a data resurrection for non geeks
Here's where it gets potentially real rewarding. CAN this group we make up work together on making such a beast? My initial project vision is to break it down to baby steps. One bite ones.
First bite being a method of scripting the backups and archiving them. That means defining WHAT gets grabbed from where when etc rules and namespace conventions to make admin less painful. Since many windows users are schiziod in their file naming we have to be mindful of that.
Second Bite being creating the restore method/s. Ranging from a web menu to ?
Third is assembling a crude demo tabletop setup for degubbing.
While it's quite psychotic to even joke about- what a mindblower it would be at ITEC if we had a demo going. Just how fast CAN a network "drive image restore" of Ubuntu with the data from a typical windows cubicle farmer's level be run? that's to say - power up with formatted blank drive to fully usable Ubuntu with local copies of files? Showing that we can image up a Ubuntu workstation and have productive work restared faster than one could restore windows would be a kudo for Linux eh?
Oren
The Bacula package is very versatile as far as backup and storage options. There is a Windows client also but I haven't tested it myself. The area requiring most work would be in implementing a turn-key restore procedure.
-Shawn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Oren Beck wrote:
First bite being a method of scripting the backups and archiving them. That means defining WHAT gets grabbed from where when etc rules and namespace conventions to make admin less painful. Since many windows users are schiziod in their file naming we have to be mindful of that.
I'm partial to partimage for system backups, which I use (combined with the fairly minimal system rescue CD linux environment) to implement windows imaging from bare metal (via PXE boot & NFS), from a 'rescue partition' on the 'doze HDD, and from DVD.
I don't think the image files created by partimage can be directly mounted, but making a read-only loop-back block driver doesn't seem like it should be that difficult (he says naively, not having looked at the image format).
Second Bite being creating the restore method/s. Ranging from a web menu to ?
What exactly do you want to do? I have scripts that run under Sysrescd that image a windows system from bare-metal across the network (including PXE boot) in fairly short order (less than 1 Min/GigB IIRC, total time depends on the file-system size), but you don't get to resize parititons or extract just the user data for some customized linux win2lin migration thingy.
- -- Charles Steinkuehler charles@steinkuehler.net
While this has already been mentioned in passing, you may find something of use here:
PING = "Partimage Is Not Ghost" This project uses a Linux boot CD to boot Windows and Unix/Linux systems and back them up to and/or restore from a single disk or partition image file on a SMB (Server Message Block or Samba) share either on a Windows box or a Unix/Linux box (including a NAS device with SMB support). While this project does not directly meet all of your criteria, it might be possible to tweak it so that it does. Perhaps setting up PXE boot on the remote system to boot from the PING CD boot image on the image server and running scripts to backup or restore individualized backup images based on the MAC address of the remote system, just as an example.
Best of luck!
Jeffrey A. McCright, A+ 816-210-3107 jmccright@hotmail.com
From: "Oren Beck" orenbeck@gmail.com To: "KCLUG (E-mail)" kclug@kclug.org Subject: Linux backup and restore server project- several particulars needed. Date: Mon, 17 Sep 2007 14:12:49 -0500
Let me start by saying I know there are packages to do much if not all of this already.
Concise statement of a non-trivial larger concept is to have a Linux server make timed backups of several windows systems in a zero user interaction format- and be able to remote restore those boxes equally "no user assist" required.
Expanding the short concept as :
Backups being BOTH data AND drivers etc.
Restore as being from a file up to a drive wipe and reload using some image system.
The simple explanation is to make supporting windows boxes a bit less painful.
The expanded explanation is as "life support" while beginning a migration to Linux. The reason is that having such a system in place also becomes a pre-migration tool. Imagine doing a ms to LNX migrate where the majority of system users would already have server resident current recently checked backups before you arrive onsite? This is one way to make that possible.
OR the much more mundane target of being a data resurrection for non geeks
Here's where it gets potentially real rewarding. CAN this group we make up work together on making such a beast? My initial project vision is to break it down to baby steps. One bite ones.
First bite being a method of scripting the backups and archiving them. That means defining WHAT gets grabbed from where when etc rules and namespace conventions to make admin less painful. Since many windows users are schiziod in their file naming we have to be mindful of that.
Second Bite being creating the restore method/s. Ranging from a web menu to ?
Third is assembling a crude demo tabletop setup for degubbing.
While it's quite psychotic to even joke about- what a mindblower it would be at ITEC if we had a demo going. Just how fast CAN a network "drive image restore" of Ubuntu with the data from a typical windows cubicle farmer's level be run? that's to say - power up with formatted blank drive to fully usable Ubuntu with local copies of files? Showing that we can image up a Ubuntu workstation and have productive work restared faster than one could restore windows would be a kudo for Linux eh?
Oren
Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
_________________________________________________________________ Get the device you want, with the Hotmail® you love. http://www.microsoft.com/windowsmobile/mobilehotmail/default.mspx?WT.mc_ID=M...
On 9/17/07, Oren Beck orenbeck@gmail.com wrote:
Concise statement of a non-trivial larger concept is to have a Linux server make timed backups of several windows systems in a zero user interaction format- and be able to remote restore those boxes equally "no user assist" required.
Define "zero user interaction format" and "no user assist", which you've already put in quotes.. Do these mean that we're allowed one or more "administrators" as opposed to "users" to install and configure the system on the backup server(s) and Windows systems, or what, exactly?
These periodic "Make it simple enough for the dummies!" exercises try my patience. There is a minimum amount of complexity involved in a backup system that can't be avoided. If nothing else, when the Windows side runs, if it does not pop up some message confirming that the backup was successful, the "No news is good news" trap is set. A failure of the backup software to run would be interpreted by the users as "everything is OK", which it isn't.
I speak from painful experience here.
Another painful fact is that backup software running under Windows seems to be unable to back up files in use. I'm not sure why this is, but I look at backup logs and see it all the time. The first lesson in the Tao of Backup (http://taobackup.com/coverage.html) teaches that every file must be backed up. As Windows typically has open hundreds or even thousands of files, precisely those most important for proper functioning, this is a huge issue.
The backup software we use for *nix backs up every single file on all mounted filesystems (with such exceptions as we may set up in a config file). It produces bootable media (CD or pair of diskettes) with which one can install a brand new hard drive, boot the system, and reload everything from tape, resulting in a fully-functional system. We don't have trouble backing up all the files under *nix, because the software doesn't try to open files in an exclusive mode.
I assume that the people who write the backup software aren't complete idiots, so that makes me think there may be a technical reason why Windows doesn't allow them to do a better job of it. It may be necessary to have software that writes an entry to the Registry, forces a reboot of the server, and then runs in exclusive mode during the boot. I've seen programs like Partition Magic do this to solve exclusive access problems. A slightly-different approach might modify boot.ini (or whatever the Vista equivalent is) so that Windows doesn't even boot at all that time, but instead loads a Linux kernel to do the backup (and then reset boot.ini to load Windows next time). Or the Windows loader could be chained off grub.
A lot of such details depend on the BIOS limitations. The proverbial "Make it unhappen" CD, which boots into Linux, checks the backup server(s) to see what's available (which might require some creative use of bootp) and offers complete images from which to restore a system. But you still will have choices to make. Someone has to decide how many images per machine to retain, then at restore time decide which one to use....
I agree with Monty here. If you want to set up some backup software which includes a server or multiple OSes, there is going to be some config required. Unless you control the server hardware, the router, the network infrastructure in general, you can't create a one size fits all solution. Someone, somewhere is gonna have to have a clue about what their IP address is, what the server IP is, or hostnames of PCs if your local DNS is working right.
I have also witnessed user error with regard to backups. The faithful little user puts in the right tape each day and runs the backup job, but the tapes are completely empty due to a failure of the drive or the software to get past an error. It takes a semi-experienced tech to figure out there is a failure of some sort and then fix it. Most times you don't need a full backup, which may take too long anyway if using tape, you just need data in one specific location.
Anyway, there are the parts out there to do what you want, but I doubt it will be turn-key and tard-proof.
Mondo and Mindi on the Linux side can be scripted to do a backup. They are included on the System Rescue CD. Ghost Enterprise has tools to do exactly what you and one of the other guys talked about with booting to a small partition and then retrieving your image, but it is not dead simple. Clonezilla is probably up to the task. You could edit the liveCD to include a custom boot script to backup to a server, but you are going to have to build that based on the network setup. http://clonezilla.sourceforge.net/ http://gparted.sourceforge.net/livecd.php
On 9/17/07, Monty J. Harder mjharder@gmail.com wrote:
On 9/17/07, Oren Beck orenbeck@gmail.com wrote:
Concise statement of a non-trivial larger concept is to have a Linux
server make timed backups of several windows systems in a zero user interaction format- and be able to remote restore those boxes equally "no user assist" required.
Define "zero user interaction format" and "no user assist", which you've already put in quotes.. Do these mean that we're allowed one or more "administrators" as opposed to "users" to install and configure the system on the backup server(s) and Windows systems, or what, exactly?
These periodic "Make it simple enough for the dummies!" exercises try my patience. There is a minimum amount of complexity involved in a backup system that can't be avoided. If nothing else, when the Windows side runs, if it does not pop up some message confirming that the backup was successful, the "No news is good news" trap is set. A failure of the backup software to run would be interpreted by the users as "everything is OK", which it isn't.
I speak from painful experience here.
Another painful fact is that backup software running under Windows seems to be unable to back up files in use. I'm not sure why this is, but I look at backup logs and see it all the time. The first lesson in the Tao of Backup ( http://taobackup.com/coverage.html) teaches that every file must be backed up. As Windows typically has open hundreds or even thousands of files, precisely those most important for proper functioning, this is a huge issue.
The backup software we use for *nix backs up every single file on all mounted filesystems (with such exceptions as we may set up in a config file). It produces bootable media (CD or pair of diskettes) with which one can install a brand new hard drive, boot the system, and reload everything from tape, resulting in a fully-functional system. We don't have trouble backing up all the files under *nix, because the software doesn't try to open files in an exclusive mode.
I assume that the people who write the backup software aren't complete idiots, so that makes me think there may be a technical reason why Windows doesn't allow them to do a better job of it. It may be necessary to have software that writes an entry to the Registry, forces a reboot of the server, and then runs in exclusive mode during the boot. I've seen programs like Partition Magic do this to solve exclusive access problems. A slightly-different approach might modify boot.ini (or whatever the Vista equivalent is) so that Windows doesn't even boot at all that time, but instead loads a Linux kernel to do the backup (and then reset boot.ini to load Windows next time). Or the Windows loader could be chained off grub.
A lot of such details depend on the BIOS limitations. The proverbial "Make it unhappen" CD, which boots into Linux, checks the backup server(s) to see what's available (which might require some creative use of bootp) and offers complete images from which to restore a system. But you still will have choices to make. Someone has to decide how many images per machine to retain, then at restore time decide which one to use....
Well, in-use files should no longer be a problem if the backup software uses Window' s Volume Shadow Copy or sometimes called Volume Snapshot Service (VSS) - which most newer ones do. I agree, backup and restore is a complex task, but I don't feel users should know anything about how it works and that includes pop-up windows telling them it was or was not successful. If they get a message everyday, most users will become numb to the repetitive task of clicking ok to a daily backup message and might not even read it half the time or at all. Its better to know something went wrong before the user tells you. Just because they get a message that something bad happened, doesn't mean they will drop everything to tell you about it. I know many will wait until they run into you in the hall, at the pop machine, or when something really bad happens and they can't work.
User: "Hey Jer, can I get you to come look at my computer? Something about an invalid disk error..." [On the walk back to his desk...] User: "I've been meaning to talk with you. My machine has been giving me these pop-up messages lately." Jeremy: "What pop-up messages?" User: "I'm not sure, something about backups. I've just been hitting ok." Jeremy: "How long has this been happening?" User: "I don't know... A couple weeks? Been meaning to tell you, just been busy." [20 mins and one failed hard disk later...] Jeremy: "Looks like your hard drive failed. I'll try some things to recover it, but it doesn't look good. I just check the backup logs... Looks like the last good backup was 3 weeks ago, hope you haven't worked on anything important since then..." User: "...." (stunned silence) Jeremy: "Probably should have told me about those pop-up windows sooner..."
See my point?
I'm all about the adage, "The right tool for the right job". If your going to be burdened with having to manage and administer Windows Workstations, use tools that work the best, fastest, and easiest for the job at hand. This usually means Windows based applications that have a friendly centralized administration interface that can scan the network or preferably integrates into your directory service of choice or at least Active Directory. I would use something that can push install its backup agent across the network to these workstations so you don't have to worry about msi files or pushing files with login scripts. Something that is probably policy based so you can work on groups of workstations and has robust reporting and notification capabilities so you don't have to rely on your users to tell you their backups have been failing.
As far as the simple home users or workstations that aren't part of a large network, buy an external storage drive. Most come with fairly decent backup software, like memeo, that offers real time continuous data protection. External storage is probably the better, relatively cheaper and safer backup medium any way.
Use Linux when its the best tool for the job. Don't sacrifice features, like any of the above I mentioned, just to be an open source purest. In a business environment, use tools that make your life and job easier and then use the time saved to work on your favorite open source project. ;-)
Anyway, just my $0.02....
-
Brian Kelsay -
Charles Steinkuehler -
Jeffrey McCright -
Jeremy Fowler -
Monty J. Harder -
Oren Beck -
Shawn C. Powell