[kwlug disc.] backups yet again

[unsolicited]

Insurance Squared Inc. wrote, On 04/03/2008 7:05 PM:
> I know there was a recent discussion on the subject of backups and 
> archiving but I didn't pay too much attention....now of course I'm in 
> need of doing the same thing.
> 
> I've got a small office I need to backup and archive.  The goals are for 
> everything to be automated, and to reasonably allow as little time to 
> restore should I have a catastrophe with one of the machines.
> 
> There's 3-4 windows boxes on the network plus my linux desktop.  Then 
> there's a seperate linux server (running centos I think) that's got my 
> client database on it (SugarCRM which is a php/mysql FOSS program).  
> That's the backup need.  I also have another mandriva server on the 
> network that runs my secondary DNS and contains my automated daily 
> website backups.  Every few weeks I dump those backups to a DVD (about 3 
> gigs of zipped data) and delete them from the mandriva machine.  I'm 
> thinking I should probably just add another 500gig hard drive to the 
> mandriva machine and use it for the office backups, and continue with 
> burning dvds.  Does that sound right?
> 
> And should I just install samba on the mandriva server and clone 
> specific directories from the windows machines daily?  Or is there a 
> better way to do all this?
> 

> It's 2008....I don't know why I don't have an automatic answer to such a 
> fundamental question :).

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.

(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?

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.

	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.

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.

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_!"