[kwlug disc.] backups yet again

John Van Ostrand john at netdirect.ca
Fri Apr 4 13:50:44 EDT 2008



unsolicited wrote:
>> It's 2008....I don't know why I don't have an automatic answer to 
>> such a fundamental question :).
There isn't a fundamental reason because people's requirements are 
different. Here are some questions to ask yourself:

1. Is off-site backup important?
2. If off-line backup important?
3. Are multiple versions required, either for the history or as a safety 
net?
4. How long should the archive last?
5. How much is it worth to your business to keep the data safe?

These are just the basic questions, there are lots more (e.g. automated 
vs. manual, recovery time, etc). There are lots of different 
combinations of answers for the above so it isn't a one-size fits all.
>
> Because the industry hasn't come up with a simple to solution for it 
> yet. Astonishingly. Biggest reasons, I think:
>
> (a) capacity to be backed up keeps growing and growing and growing - 
> the idea of backing up to DVD or tape is just ludicrous. [Vs. (a) 
> archiving, (b) multiple disk repositories, preferably in multiple 
> locations.] Mind you - if you can nail down your ultimate / final 
> backup period you must have, a, say, monthly append to redundant DVD's 
> of any file in the backup archive that just went over 2 years old, 
> makes some sense.
Government regulation is a big part of this. Things like Sarbanes-Oxley 
for US companies and I believe there are regulations requiring life-time 
storage of medical data like high-res images.
>
> (b) each element in the landscape to be backed up has it's own 
> requirements as to how you back it up. e.g. Windows vs. Linux.
>
> Rule of thumb: BACK UP EVERYTHING. The mindshare time it takes to 
> figure out which parts of a system you need, and which you don't, just 
> isn't worth your effort. Let alone the worry sitting in the back of 
> your mind - "Did I remember everything I might possibly need, and are 
> the stupid users now going to save something outside of what I set to 
> be saved?" You did want to sleep at night, right?
This is one that I have to tell people all the time. The most sure 
backup is a complete backup. There are some that can get away with 
partials but it's a ticking time bomb. Everyone will miss something 
given enough time.

>
> Unfortunately, you're going to need to come up with a backup strategy, 
> and no one size fits all. And all I mean by that for the moment is 
> figure out each step in the backup. e.g. (1) Backup OS partition to 
> local disk. [Particularly windows.] e.g. C: -> D:\Backup\C, (2) 
> Replicate local backups to central backup repository, probably by 
> rsync. (3) Redundant backup from that repository to another (4) Repeat 
> 3, perhaps, off-site, off-building, or at least in another secure room 
> / basement, or to a 3rd party provider. (5) Figure out how you're 
> going to manage the growing size of the repositories - another disk, 
> write some off to removable media, purge, what? e.g. Perhaps you 
> nightly purge all .tmp, ~ and other files that are only temporary / 
> probably unnecessary in a restore.
>
>     All of the above give you multiple levels of redundancy, at 
> multiple age levels.
>
>     You will also need to decide on some overall aspects - e.g. Get 
> all logs to a central place, and have them checked, daily. Scripting 
> would probably be useful. Since each piece may have it's own logging, 
> post-piece grep / scripting depositing success / failure to a central 
> place would be useful.

In my opinion automated backup is essential to a good backup strategy. 
It removes the chance the backup will not occur due to forgetfulness or 
procrastination. Automated backup has it's problems (failure to read 
logs as Bill points out) but in our experience it works out better as 
long as you have certain guards in place. Here's how:

Force cycling of tapes: In other words don't allow last night's tape to 
be overwritten by tonight's backup. I know what you're thinking, if 
forgotten tonight's backup won't happen. Read on.
Emailed backup reports: The backup report is emailed to more than one 
user who's job it is to replace backup tapes. Inside the report is the 
label name of the next tape to insert.

The result of the above is that users become more responsible. I don't 
know why, but I bet it's because they feel more accountable. They need 
to change the tape or the backup doesn't happen. In order to put the 
correct tape in so the backup happens, the user needs to open the backup 
report.

>     John has presented on Amanda before. There is DAR and rsync out 
> there. I am an expert on none.
>
> For windows:
> - keep OS partition as small as possible. 5GB - 10 GB on anything but 
> a developer workstation. Nothing else belongs on C:, particularly 
> things like SQL and Exchange, which have their own backup mechanisms.
> - nightly C: backup via ntbackup to D:, with Shadow Copy enabled.
> - nightly non-C: backup of self-backup-mechanism applications, such as 
> Exchange or SQL, somewhere. e.g. SQL transaction logs to D: somewhere.
> - nightly backup of all non-C: somewhere, e.g. rsync.
>
> For Linux - same thing, take everything, but I don't think you need to 
> keep it local. i.e. The only good way to back up windows is ntbackup, 
> and you don't want to be throwing huge .bkf files around if you can 
> avoid it. The various backup apps, e.g. Dar, have pretty well defined 
> things you don't need to take, e.g. /dev. Others will know better 
> than  I.
We've had trouble getting the amanda client for Windows to work, but 
that was a while ago and things change. The Amanda client at the time 
didn't support backing up Windows meta data well. Things like Active 
Directory and other databases weren't done well and a bare-metal restore 
may not be possible. We sometimes setup NTBACKUP jobs to dump files to 
local or remote disk and backed that up. Still not bare-metal restore, 
but at least it's an AD and Exchange backup.
> Beyond that - there are better experts here than I.
>
> MS has a free NFS client/server for Windows. I found it completely 
> useless on XP. Cygwin has an NFS server (client?). NFS is supposed to 
> have some advantages, e.g. more robust connections. I'm only talking 
> about getting files off of Windows to a Linux environment wherein, at 
> least, you can use the same common set of tools across the remaining 
> machines.
I'd personally go with Samba, although make sure you script it well 
enough to know it's mounted. Either way you would miss the permissions 
with a network-file-share backup but in some cases that's okay.

> You'll have to decide for each machine if you want to push the 
> backups, or pull them. With rsync, you can do both. (Just watch you 
> don't replicate deletions from the store back to the workstation!)
>
> Lucky you - you get to join the choir of all of us in saying "It 
> should _just_ _be_ _easier_!"
For the cheap disk-to-disk backup I recommend rdiff-backup. If your data 
doesn't change much and you don't mind your backup being on-line you can 
do this across the Internet to provide off-site, multi-age backups. 
Cygwin has rdiff-backup and it's requirements for Windows and as a bonus 
you'd get SSHD for Windows.

In the end we still recommend LTO tape (400/800GB per tape) and a tape 
library if you need to store more than one tape can handle. The tape 
library is a very pricey by personal standards but businesses tend to 
look at the $8k or so for a 45 tape library (that's 36 Terabytes of 
storage) as being cheap. We have one here at Net Direct and use Bacula 
on our Linux servers to backup.

-- 
*John Van Ostrand* 	*Net Direct Inc.* 	 
CTO, co-CEO 	564 Weber St. N. Unit 12 	map 
<http://maps.google.ca/maps?q=564+Weber+Street+North+Unit+12,+Waterloo,+ON+N2L+5C6,+Canada&ll=43.494599,-80.548222&spn=0.038450,0.073956&iwloc=A&hl=en> 

  	Waterloo, ON N2L 5C6 	 
john at netdirect.ca 	Ph: 866-883-1172 	ext.5102
*Linux Solutions / IBM Hardware* 	Fx: 519-883-8533 	 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.ccjclearline.com/pipermail/kwlug-disc/attachments/20080404/82bedabd/attachment.htm


More information about the KWLUG-Disc mailing list