Lux Interior asks:
"Help! I am the ad-hoc computer guy in a small satellite office of a larger company. We have no CIO, no IT department, and no policies whatsoever as regards data retention or backup. Therefore, a lot of company property exists one place-- on individual hard drives. The office is made of almost entirely of rudimentary users, on WIN98 and 2000 machines, who never, ever, back up any company information. Has anyone out there had experiences in a small-office setting with: changing users' behavior in regards to managing their data; setting up best practices for backing up information properly; and making sure that the most computer-apathetic users comply with what you've put in place?" Sometimes the best way to make users conform to policy is to not give them a choice in the first place. Automated backup systems on each workstation can go a long way in helping this. Which software packages have such functionality (the more unobtrusive, the better)?
"Several weeks ago we lost six years' worth of extremely important data on current and continuing projects that not even a data recovery service could get back. As a consequence, it is now my job to make sure this doesn't happen again. I have an offsite data storage service retained, but now, how do I get people to back up their files to our file server so I can back up our data from one location? (Also, having the data backed up on our file server of course means that most inadvertent deletions can quickly be fixed in-house).
This is all taking place in a Windows environment, with an NT 4.0 file server, and I am far from an experienced Sysadmin.
Fun, Fun, Fun.
Any input from slashdot readers would be great, and save me much dyspepsia, insomnia, and general hassle."
Slashdot Mirror
Create a network drive that everyone can use, H:, the home directory. Usually already set up on networks, but whatever. Tell people that any work related stuff that isn't saved to the H: drive will be deleted.
Warn them a week in advance, warn them a day in advance.
Then, in the middle of the night, format everyone's machines and stick fresh OS installs on all of them. If possible, ghost one machine's fresh install and use it everywhere. Then, the only backup you have to worry about is the H: drive.
If anyone ever has a computer problem, just reghost their drive, removing whatever pointless software (screen savers, comet cursor, kazaa, etc) that got installed and caused the problem.
Minimal hassle for you, easy backups, and everyone will fear you.
[o]_O
Changing people's philosphy on where to store data goes a long way.
We have a server with a large-enough tape drive to back up users' data. We then encourage people EXTREMELY to save important data to their personal LAN Drive, and eeinforce the idea that the Hard Drive should be considered expendible. No excuses, no tears.
We then back up the data nightly and rotate tapes daily during the work week (M-T-W-TH, and Weekly Friday Tapes, with the Last Friday of the Month going on rotating Monthly Tapes.
It a bit of habit-breaking for people used to saving everything to C-Drive, but a little Pavlovian experience of "Ohmigosh, my file is gone!/Oh wow, you got my file back!" will reinforce people that Hard Drives Are Bad/LAN Drive is Good.
You can even reinforce the idea with encouraging people backing up files on floppies/CD R/W Drives.
Mod Karma -1: I sed bad wurds. If I cep my mouf shut, I wud be at riyses.
While I'm in a Mac environment, I believe Retrospect is fully cross-platform.
What we did here before we went to a centralized server architecture is we ran full backups once a week (and incrementals every night) from the users' desktops to a backup server, then backed that up to DAT (this was years ago - now I'd use DLT).
With Retrospect client on every desktop machine, you can unobtrusively cause each desktop to be backed up in the middle of the night, when network traffic is light and files are not in use. If the user shuts down, Retrospect interrupts the shutdown process and waits until the backup is completed before allowing the machine to power off.
It's also real good at preserving the state of the system, making it easier to restore from bare metal.
http://www.dantz.com
Then become the data gestapo and slowly, kindly, patiently drill it into their head to always save things into "My documents." If they ask you to help them with their computer, and you see files that should be in the "My docs" folder, move them there, after they get used to always loading stuff from there, they will get used to saving there too.
The key is patience and Persistence. Practice your waitress smile! ;)
What are we going to do tonight Brain?
This is not a technical problem, this is mainly a behavioral and cultural issue.
Users aren't going to do *anything* they don't prefer to do, and you have no way of compelling them to do the "right" thing. The post about domain logons and establishing "My Documents" on the network server is excellent, but the users could still save everything on their C: drive. (They probably will because a network share is usually slower than the local hard drive, and they're used to using C:.)
My recommendation would be to gain and establish management support for a backup policy. To do this, you will have to demonstrate to management the risks inherent in not compelling users to back up their data - such as loss of operational data, client lists, engineering data, etc.
Ideally, management would issue an edict that specified that employees were responsible for cooperating with your backup regimen.
Short of this, it ain't gonna happen, because users are basically "stupid". (Defined as shortsighted, unable to see the big picture, unable to imagine loss of data, etc.) And without a real enforceable policy with disciplinary measures in place, they are going to skirt the policy, count on it.
Check out Retrospect by Dantz software. We use it for a mixed network of Macs & PC's. Backup occurs automatically from all workstations at administrator defined times. This way, you don't have to "teach" everone to store to a network drive or anything like that.
Dude! Don't crash or deliberately mess someones data up. First of all it is morally wrong, second is if you got caught then your are toast. Most people would fire you on the spot.
Lastly you don't have to do damage to data at all. Give it time and people will mess up. Then if you restore the stuff quickly, they will start using/trusting you more.
I do agree with putting the "My Documents" folder on a universal share. The only issue that could come is space and reliability. If the NT box dies regularly or you are running low on space a lot, this will cause issues.
The more I learn about science, the more my faith in God increases.
Get a tape drive and Retrospect from Dantz. If you only have one NT server, you can get Retrospect Workgroup; otherwise, you'll need Retrospect Server. You install the client software on each workstation or server you want to back up, and install the server software on the machine with the tape drive. Then you just activate all the clients, create a couple backup scripts, and change the tape every night before you leave. All this is really simple to administer because Retrospect was originally designed and written for the Macintosh. It's also fairly inexpensive, at least compared to (a) the cost of your time trying to roll your own backup solution and (b) the other backup systems on the market (which are often harder to administer and less functional).
Retrospect can easily be configured to yell at users that haven't been backed up in a certain amount of time, to either back up their entire machine or just a part of it, etc. You'll still have to get users to leave their computers on, but that'll be the extent of it.
I prefer whole-machine backups; everywhere I've used Retrospect, that's what we've done. Retrospect is smart, so it won't back up 10 copies of an identical file just because each one is on a different computer. And Retrospect also does incremental backups out of the box, so you're only backing up what changed *and* you can restore a machine to exactly the state it was at at the time of any given backup.
Sorry for the commercial, but I've been using Retrospect for my own network for 6 years now and have done work for shops that use it for 9, and I have yet to see a better backup solution.
I don't know about this guys situation, but in some companies it is part of the admins job description to take every reasonable action to force users to "do the right thing". Having them sign a document absolving him/her of guilt would just not cut it. In his case, he should put in place the appropiate software/hardware to implement a backup system and ensure that it is either hard or impossible for users to do the wrong thing. At the absolute very least the workers should be trained on the new/proper procedures (and reminded as appropriate). The idea of a sacrificial lamb mentioned earlier would be interesting, so long as he made sure to have a copy of all the important data first (i.e., I'd fire his ass if he pulled a stunt like that and intentionally destroyed valuable company data).
--
SuiteSisterMary:
MAKE DAMN SURE YOUR BACKUPS WORK, OR YOU'LL LOOK LIKE AN IDIOT.
Speaking as a former idiot *koff*, that goes without saying.
Any backup system should be tested and shaken-down to verify that data is recoverable. (Then again, any good autobackup system should have a Verify Mode, and a log of the backup to review the morning after.)
The amount of blood, sweat, toil, tears, and non-comped off hours will be worth it.
Mod Karma -1: I sed bad wurds. If I cep my mouf shut, I wud be at riyses.
Pay attention to the parent post here - this is excellent advice.
Backups for workstations are difficult and troublesome. I've never seen this work worth a flying turd in any kind of production evironment.
Far and away, your best bet is to migrate everyone to start saving ALL company data on a file server, preferably with some kind of RAID array for redundancy purposes. Again, as the parent post had pointed out, it's a relatively simple process to migrate everyone's "My Documents" and such to some share on your file server. If you're running Win2K, active directory can help out with this tremendously, but poledit for NT should work just fine - you might even be able to get away with something simple in the guise of logon scripts, reg files, etc.
The sacrificial lamb is also good advice - it may seem a little underhanded, but believe you me - your point will be made in a way that will stick to even the "I-can't-be-bothered-to-learn-how" types. Remember, these are tyically the ones who will be the first to crucify you in the event they lose something, and the ones you'll need to make the point across to the most.
As far as physical backups go, if you're pretty well sold on NT as the platform, then BackupExec form Veritas is a great package that I've had excellent results from, but it ain't cheap.
If you can manage to get away with using a Linux/*BSD/whatever running Samba for your file server, you may have some luck with some open source backup software (much more economical, but you will need to hit the books to get it done right without some consultants). They're pretty good from what I hear, but I haven't had much of a chance to play with them.
You'll also want a tape drive and robotic loader for your file server. These ain't cheap either, but believe me you can sell it to the suits as a necessary expense. Unless they don't value their data, that is.
"Oh my God! The dead have risen! And they're voting Republican!" - Bart Simpson
I wrote a 20 line shell script that uses 'nmblookup' to find all the luser's machines, scan those machines for [A-Z]\$ administrative shares with 'smbclient', and generate amanda's disklist file from that.
Nice thing about amanda is it self adjusts. Someone takes a laptop home for three days, comes back, and amanda will pick up where is left off. Nice.
Before I part with'em: two pennies weigh ~4.996+/-0.014g, have a zinc core, and the face of Lincoln. You can keep 'em.
I would advise against a waiver. Its likely the users would complain to this guy's boss and get him trouble. Users=lusers and they want to have someone to point there fingers at when things fail. They want there problems solved by someone else and if shit happens THEN ITS THE HELP DESK GUYS FAULT AND IF HE/SHE CAN"T GET IT BACK THEN FIRE THEM! I use to do helpdesk and it was the shortest job I have ever had. The network goes down due to a miss configured router=my fault, user unplugs lan hub underneath desk for a lamp causes her boss to unaccess her mission critical project due in 1 hour=my fault, user's hard drive fails and she never backs it up and co-worker screws up backups= my fault and she calls my bosses boss and gets me fired even though I didn't fuck with the server tapes! This happened 2 years ago and I am still very angry over this because I couldn't fin another IT job before the .bomb .
:-)
Anyway here is a more non confrontational method. Just setup a user policy and have it downloaded automatically when each user logs in. In that policy map the users default drive on the server. Make sure the users name is on each subfolder on the servers main backup folder. This will make a big difference to clueless lusers when they see there name on a folder that ms-word tries to automatically save in. You may want to put a greeting pop up message in their profile when each user logs in and telling them to save there files with the directory with there name on it. THen send an email out to everyone and warn them that hard drives tend to fail and just tell them to save all their work with the folder with their name on it. Sounds simple. right?
The program to do this is called poledit and its on the windows cd. To have the profile downloaded automatically you need to create the profiles and then go to user manager and setup it up to download automatically when each user logs in. This is what I would do. If shit hits the fan you can tell management what you did with the pop-up messages, the email's and the profiles and that it was the users fault. With all of these things combined, the blame factor will move away from you and towards the user. Unless of course the server dies.
But I advise not to have users sign anything. It makes them angry and uncomfortable and they could get you in trouble. Remember that IT is customer service just like any entry level job. The customer is always first and its your job and not there's to make sure the data is backed up.
http://saveie6.com/
Assuming you're a Windows shop, put 2K (or XP I suppose, possibly even nt4) on the laptops, and use the 'synchronize network share' options. This'll take care of it all for you, and let those roadwarriors have all thier docs.
Vintage computer games and RPG books available. Email me if you're interested.
Additional clarification: Buy a good tape drive. Do not let cost be your guide; buy the best-rated drive you can find. Again, if they give you grief about the drive's cost, the parent poster's advice still applies.
I used to work at $(MUMBLE_SALTPILE_MUMBLE), whose IT department was staffed by people of diminished capacity. One day, due to a re-org, they physically moved a server containing critical data. Somehow, the move killed the drives. So they went to restore from backups.
During the restore, the drive ate itself and the tape. Backup destroyed.
Now, because the IT department had the aforementioned staff of diminished capacity, the next available backup was a week old (it turns out they were doing daily backups serially onto the same tape, because it was "faster").
So the lessons here are:
Schwab
Editor, A1-AAA AmeriCaptions
My experience is that the less your users have to do with backups, the better - they click through error messages, they don't read EULAs, they will not take the care you will because it is not a concern they have internalized. In general, it needs to be as automatic, hands-free and brainless as possible. REMEMBER, SIMPLE == GOOD, COMPLEX == BAD! However, you also need to realize that the backups procedures are just one part of the larger picture. Simply backing up isn't good enough, you need to create a situation where they don't have to make decisions about backing up. From their perspective, they have to just remember to keep their files in X location and the backups will just happen.
Here's (roughly) what I did:
Create a folder to hold all user files on the server, say "Files". Make sure this folder gets backed up. :)
Share the folder, and create a logon script that every user runs at logon to map this share to a COMMONLY AVAILABLE drive letter, say W:.
On W: Create several top-level folders: Private (create a folder in here for each user accessible only to them) Shared (create folders here that need to be shared by groups) Apps (create folders in here to hold for application files and data used by programs) Software (for program install files) etc...
Make sure security is set up to PREVENT users from saving files where they do not belong (like the root of W:). You may want to create a user group for each folder and use membership in that group to control access to the files. They should have to come to you to create a new folder for them in most cases, that gives you the opportunity to review the request with your superiors to ensure proper Policy & Procedures are being followed.
Teach your users this mantra "PUT ALL FILES ON W:" Put it in your email sig, your memos and on your voicemail! Use it in casual conversation - I'm not kidding, REPETITION!)
Go to each PC and move their files into their W:\Private\username folder.
Delete the moved files from their hard drive.
Reset all apps (word, excel, etc.) to default open/save on the W: drive.
Your goal should be to reprogram them to think of the network drive as the only place there is to save files.
"Lawyers are for sucks."
- Doug McKenzie
Where I work, all Linux users NFS mount their /home directories (via automount and NIS) from a central server. They can log into any of our workstations, and have all of their desktop preferences and files.
:-)
All of the Windows machines are on a domain that's handled by the same central server running Samba. They can log into any Windows machine, and all of their preferences and files are there waiting for them.
Backups are done nightly to a DLT 8000 drive that hangs off of the central server. This has saved people's asses many times when a machine blows up (sometimes literally).
With 120gig drives as cheap as they are, and entry level robotic tape changers on the market for less than $10,000, there's no reason anyone should have to suffer through a loss of critical amounts of data.
I sleep very well at night with this arrangement.
Any regular processing that requires human intervention is setting
yourself up for failure, not setting yourself up for success. People
are people, and we all forget things. Working late, bleary eyed, the
best of us can forget to "copy files to the network server for back."
Suggestions as to have users sign papers to say I know I need to back
up, and if I don't it's my fault, yada yada are bad too. That's not
solving the problem, that CYA. Lame.
Workstation backup isn't that hard. If you totally lose a drive, all
you need to restore it are the app and OS binaries, and the user's
data. The app and OS are on CD's, so those serve as backups for that,
so it's the user's data we need to focus on.
Designate a few folders to back up. E.g. where-ever email is stored,
the desktop, a user folder (if it's in windows, Documents and Settings
is a good one, as a lot of programs default things to save in there.
if it's unix, just make it the user's home directory). You don't need
to backup the entire drive. In fact, that's more than likely a waste,
except in a few cases.
Users can easily understand the should work in a specified folder or
folders underneath that folder. This doesn't require an additional
step (it's still just saving), it's a matter of where they're saving.
Are there hypothetical holes still? Sure. Do they happen in practice
that often (if ever)? Not really. If you're super paranoid (or super
diligent, depending on how you look at it), you can write a process
that looks for modified files outside the targeted back up region. If
it's a file common on a lot of machines, it's probably a standard file
(e.g. a config, preference, etc.), and you can most likely whitelist
those. Others could notify yourself (or the user) via email, and
politely ask that they move it if it is to be backed up.
Lastly, *test* *your* *setup*. This cannot be emphasized enough. You
don't need to delete a user file or anything dumb like that. Just
ask someone to name a random important file, and confirm you can
restore it to a different drive. Or pretend your production server
just crashed and you need to bring it back.
This has two key advantages: 1) obviously confirms your setup works,
2) lets you get comfortable with the restore process in a non-stressed
manner, which things going wrong is okay. You don't want to be trying
to figure it out when you're already stressed out because things have
gone horribly wrong.
Anyway, HTH.
-Bill
SlashSig Karma: Excellent (mostly affected by moderatio
The environment I work in has about 20 users using win98se, XP, 2000, and NT 4.0.
/compact", 1, true
I setup a File Server and a Backup Server. I use a script to copy everything from the File Server to the Backup Server every night and then pkzip everything into a single large file on a nightly basis. The script generates a unique filename using the date. (eg: 6132002.zip).
I find this procedure the most versatile and convenient, as I only touch the backup server whenever the drive is close to filling up. I get an archive of all the daily changes made to every file. And I can quickly and conveniently access and manipulate all the files anytime (unlike Tape.) Of course if your company deals with large poorly compressible files (multimedia), this is not as effective. (BTW, pkzip has final zip size 2gig limit. I believe bzip has a 4 gig limit.)
Of course this is not a mission critical enterprise solution. (offline storage, offsite storage, etc.) But the raid and 2 separate servers gives me enough assurance for our small company's modest computing needs. (add a tape system if you'd like anyway)
The procedure:
Setup a File Server that everyone is mapped to upon logging in. (eg: N:\ drive)
Force all users to save everything to the mapped drive. Our company uses MS Outlook, so I have saved all the PST files to the file server as well.
Make sure the File Server is configured with 2 large drives in RAID 1 (mirrored. Software raid will be sufficient, otherwise get a $50 IDE RAID card). As this will be a production server, go with 7200 RPM drives. Size will not be an issue for most office environments saving word, excel, and access files.
Setup a Backup server. Any spare old computer will do with a 100MB NIC. Install 2 identical IDE HD's and run them in RAID1. 5400 RPM will be enough as the bottleneck will be the NIC and performance will not be an issue. The bigger the better. (eg: 120Gigs)
Write a script file. Mine is written using VBS. I use the command line version of pkzip in the script. I've attached it below as a reference.
In the future, I plan to replace our NT 4.0 file/backup servers with Redhat+Samba.
BTW, I've tried using Ghost, which is a great little program. However I don't find it as useful because of the diversity of hardware and licensing. So I end up with quite a few images for a small number of computers.
The script: (BTW, Copyall.bat is a dos batch file to copy all the files from the File Server to the Backup Server.)
'Backup.vbs
'Edwin Park 02-28-02
'CopyAll.bat will copy over files from File Server.
'Then Backup.Vbs will pkzip them locally using the date as the filename.
Option Explicit
Dim strDate
'pull out the "/" character because files cannot have "/" in them
strDate = Replace(Date(), "/", "-") 'strDate = 2202002
Dim WshShell
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "CopyAll.bat >> copylog.txt", 1, true
WshShell.Run "pkzip25.exe -add -nofix -recurse -path=relative e:\backup\archive\" & strDate & " e:\backup\backupNight\*.* >> ziplog.txt", 1, true
'file "02202002.zip" is created
'Compact the database
WshShell.Run """c:\Program Files\Microsoft Office\Office\Msaccess.exe"" n:\DB_Shine_2000.mdb
Set WshShell = Nothing