Answered by:
WHSBDBB vs. dual boot machine for backups

Question
-
Which is the better WHS backup scenario and why? (1 drive WHS system)
1) disconnect the existing WHS drive, install a new drive, install some version of Windows with 2 partitions on the new drive, reattach the WHS drive, reboot and tell WHS not to add the newly added drive to the storage pool, edit the boot.ini file to allow booting to the new drive (instead of WHS, as needed), and boot to the new drive and use robocopy of the WHS files when I want to back up the server.
2) install an additional drive and use the WHSBDBB add-on
Thanks in advance for any reply.Friday, November 21, 2008 4:52 PM
Answers
-
To confirm, the steps you describe are the exact steps performed by my WHS BDBB add-in, as they are/were documented in the Backups whitepaper.
http://www.mediasmartserver.net- Marked as answer by Alex Barimo Saturday, November 22, 2008 4:56 AM
Friday, November 21, 2008 10:25 PMModerator
All replies
-
Option 2 is the better, IMO. Windows Home Server is not designed to be used interactively, with connected keyboard, video, and mouse. Indeed, during the public beta, there was specific mention in the installation instructions to "disconnect your keyboard, video, and mouse" once the basic installation was complete.
I'm not on the WHS team, I just post a lot. :)Friday, November 21, 2008 5:33 PMModerator -
Thanks for your reply.
On option 1) when WHS is running no keyboard or mouse would be connected.
When booting to the other Windows OS, WHS wouldn't be running.
Is there any other reason that option 2) is "better"?
I'm aware that robocopy may not copy all files (i.e. the "insufficient resource" problem, etc), but the robocopy option isn't robocopy specifically, rather some generalized method of copying files from the DATA volume on the WHS to a volume on the drive with the non-WHS Windows (i.e. the 2nd volume on the non-WHS Windows boot disk).Friday, November 21, 2008 5:36 PM -
Your option 1 requires you to configure Windows Home Server in a dual boot configuration (which is unsupported and not easy to do, as you seem to recognize). For convenience, you would probably leave the physical console connected all the time (I know I would get tired of all the reconnecting after a couple of rounds). In addition, an unsupported hardware/boot configuration runs that risk that at some point in the future, Microsoft will make a change to WHS which will "break" your dual boot server. Finally, the essence of a server is that it's available to work at any time.I'm not saying you shouldn't try it, however. I'm saying that what you're proposing is risky in ways you may not be considering; the above is only the most superficial treatment. :) So if you try it, be cautious, and test thoroughly. Remember that Windows Home Server is not a desktop operating system. It has a great deal in common (conceptually) with small storage appliances; typically those are left alone to perform the tasks they were purchased for. Windows Home Server is a better tool for the modern connected lifestyle in my opinion because it's more flexible, and it's extensible through add-ins (or if you're adventurous and technically proficient, through the installation of programs and tools from the desktop).
I'm not on the WHS team, I just post a lot. :)Friday, November 21, 2008 5:52 PMModerator -
Instead of the above, is there any reason that stopping the backup service from within WHS, robocopying the files to the 2nd hard drive, and restarting the backup service is a bad idea?
Thanks in advance for any reply.
(nevermind - looks like Microsoft documented how to do this, i.e.
To copy the backup database from your Windows Home Server
1. RDP to server
3. Open a Command Prompt, Click Start, Run and type CMD
4. Type net stop PDL.
5. Type net stop WHSBackup to stop the Windows Home Server Backup service.
6. Copy the contents of D:\folders\{00008086-058D-4C89-AB57-A7F909A47AB4} to the hard drive
7. Type net start WHSBackup to restart the Windows Home Server Backup service.
8. Type net start PDL.
)- Edited by Alex Barimo Friday, November 21, 2008 6:56 PM found answer
Friday, November 21, 2008 6:08 PM -
So my remaining questions on this issue are:
1) The document http://download.microsoft.com/download/1/8/0/18096c95-4850-4176-9821-970691b98aaf/Windows_Home_Server_Home_Computer_Backup.pdf appears to be no longer available on Microsoft's website, although it is available here.
This document describes how to do a backup of the backup database. Has this document been removed because the information contained therein is no longer valid?
2) If the document above is still valid, Microsoft specifies that backing up to an external drive is required. Is it not OK to back up to an internal drive (not added to the storage pool), and if not why not?
Thanks in advance for any reply.Friday, November 21, 2008 7:02 PM -
I haven't attempted to configure Windows Home Server as a dual boot machine; I see no need to do so (and in any case, my production server is an HP MediaSmart Server, so it would be quite difficult). There are a number of reasons that I can think of for not doing it, but at least to a degree they come down to "it's not the WHS way." WHS was designed with the expectation that it would have complete control of all the hardware, and moving outside of that has risks. For example, adding a drive to the server that's not in the pool, for whatever reason, exposes one to a risk of accidental data loss, if one should select the wrong drive to add to the storage pool at some point.You would do well to read the technical briefs, reviewer's guide, getting started guide, etc. on the support page of the Microsoft WHS site. I think it will give a better picture of what areas are riskier to experiment with, but the general rule of thumb is that if it requires you to use any interface other than the WHS Console application, the shares, or the Remote Access web site, it's unsupported and therefore has an element of risk.
I'm not on the WHS team, I just post a lot. :)Friday, November 21, 2008 7:04 PMModerator -
The document has been superceded by the one on the WHS support page. The information about backing up the backup database is valid, however.As for internal vs. external drives, if you're going to the trouble of backing up the backup database to other physical media (I don't; I agree with Microsoft's design philosophy in this case, which is that the backup database is essentially fungible) presumably it's to protect you in case of disaster. In that case, why would you use an internal drive, when you can take an external drive and store it off-site so much more easily?
I'm not on the WHS team, I just post a lot. :)Friday, November 21, 2008 7:08 PMModerator -
Thanks for your response.
I guess because I happen to have another 1TB drive in the WHS Server?
Also I'm trying to keep the backups even if the WHS drive failes, not protect the backups in the event that the WHS machine burns up in a fire. In that unlikely event I'm prepared to reimage all the machines on the network (they aren't local).
So this script works:
net stop PDL
And when the WHS drive fails, I perform a full reinstall of WHS, stop the services on the new install and copy back the above folder and I'll get all backups and all files back (but won't get user accounts or passwords, etc.)?
net stop WHSBackup
mkdir %1
robocoppy D:\folders\{00008086-058D-4C89-AB57-A7F909A47AB4} %1 /z /e /xo /r:0 /w:0 > %1.out
net start WHSBackup
net start PDL
Somehow that sounds wrong to me. Does this really work?Friday, November 21, 2008 7:15 PM -
I wonder why MS had to remove this functionality out of PP1 if this is all there was to it.
I also like how in their guidance they use the word 'copy' without specifying how to copy. SBS 2003 can fail on copying large numbers of files (or large files, including xcopy /z). Even robocopy can. I wonder how the fellow who wrote the add-in is copying these files. Probably something in System.IO. .net isn't exempt from this problem.Friday, November 21, 2008 9:23 PM -
To confirm, the steps you describe are the exact steps performed by my WHS BDBB add-in, as they are/were documented in the Backups whitepaper.
http://www.mediasmartserver.net- Marked as answer by Alex Barimo Saturday, November 22, 2008 4:56 AM
Friday, November 21, 2008 10:25 PMModerator -
Alex Barimo said:
I wonder why MS had to remove this functionality out of PP1 if this is all there was to it.
I also like how in their guidance they use the word 'copy' without specifying how to copy. SBS 2003 can fail on copying large numbers of files (or large files, including xcopy /z). Even robocopy can. I wonder how the fellow who wrote the add-in is copying these files. Probably something in System.IO. .net isn't exempt from this problem.
As I've said elsewhere, I believe Microsoft removed this functionality because they found that they could not make it robust and simple enough for the primary target audience. What you described is easy for a technically adept person to implement manually. But to wrap that up in a single simple command that doesn't potentially leave an end-user in a very bad place if things go wrong is not nearly that simple.
I'm not on the WHS team, I just post a lot. :)Saturday, November 22, 2008 3:33 AMModerator -
Alex & Ken
Thanks for your reply and your help. I appreciate it.Saturday, November 22, 2008 4:56 AM