I have noticed at my place of work that there is an attitude that backups are not very important (certainly, development/testing happens before any form of backup strategy is in place).
Because the rest of my team are not system admins/lack system admin knowledge like me, backups/disaster recovery considerations are talked about but don't get implemented. There is an attitude that because nothing has gone wrong (but an overlooked thing is accidental deletion), then we don't need to worry too much about backups.
How do you tackle this culture? I'm sure it must be common?
Thanks
Guilt and plausible disaster scenarios are a good start, but nothing teaches like a real disaster barely averted through heroic efforts. It took us a couple of years to convince the powers that be that our tape libraries needed replacing. It took far too much effort and we didn't get what we needed (we had to settle for SDLT320, couldn't afford LTO), but at least it was better. Each time TPTB get a wild hare about must be fully replicated! Must have a hot-backup site! we duly budget out what it would cost, and every time they decide they can't afford it.
Except the most recent round. For a wonder they decided the middle-tier storage array could get live replication. The top tier is... going to wait for its replacement, if at all. The bottom tier fell off the back of the budget.
It takes constant effort, and is very wearying over the long haul. So far we haven't had an educational disaster yet.
More generally it takes education and perseverance. Education as to risk factors and likelihood of same (also known as 'risk management', they're supposed to teach that kind of thing in business schools), as well as mitigations and costs. If you have to go there, drawing up a detailed report of exactly how screwed the company is if a likely disaster case arrives and how much money would be lost by not addressing the problem is a good start. That's doing their job for them, but sometimes you have to in order to get the right thing done.
Unfortunately, it still won't help if they decide you're just scare mongering and ignore you. At least you now have a paper trail showing you knew about the problem, tried to mitigated it, and was denied, in the event of an actual disaster. Have a near miss? Trot out that report again and see if the rose color has rubbed off their glasses yet.
I've encountered this attitude more than I'd like to see in my professinal consulting career.
About all you can do is attempt to educate the client as to why its important. Hopefully they will listen and decide the right things to do. In the final analysis, it is THEIR decision afterall good or bad.
What happened in one case, was with a startup with everything on one machine including a couple of Oracle databases, no backups and not wanting to send the time and effort in generating such. It was just fascinating just how fast this company changed their minds once their primary system got a hardware glitch (non-disk). I was also amazed by the point that a significant website book author who was partial owner would allow this situation to happen and continue.
This is a discussion that requires business leadership involvement, including risk management if you have it. A good way to start the discussion is by providing an executive summary of the backup services you're providing now and asking for their involvement in determing if the service meets operational and legal requirements.
Prep for the meeting by documenting your backup service..some things to consider:
Be honest with where the service stands now no matter how it might reflect on the professionalism of IT or the inattenion of business leadership to the topic. It's important it gets done right and good business leadership will hopefully recognize this and appreciate the fact your trying to bring a transparent level of management to the process. Furthermore, an honest assesment often times brings just the right amount of reality for executive leadership to realize a.) they need to be engaged, and b.) you pay for the level of service you get.
During the project (it's going to be one), document everything. Document the business needs, document the technical implementation, write a service level agreement and get business leadership sign off upon implementation.
Good luck.
If you want them to change their mind, force them to sign same paper where you inform them that they should backup and that you are not responsible in case of disaster. Usually people don't want to sign up and begin to think. Come back 2-3 days later (if not too late)
Find some data that's important to them but isn't backed up and move it then wait and see what the reaction is.
I've had a few departments whose first hint of "getting it" has been when they've been stood at the end of my desk with a smoking laptop asking if there's any way I can get the data back off it.
There is a point where all you can do is have a policy in place that states what will be backed up, when it will be backed up, and who's responsibility it is to put data in that location, beyond that you have to assume users will take a little responsibility - which some won't, but there's always a hardcore who expect you to literally think for them.