21

Obviously, securely backing up sensitive data is a challenge. A remote backup is important for surviving a variety of disasters. What are some of the "gotcha's" lurking out there, and what best practices can avoid them?

To make it a bit more concrete, consider e.g. a small business on a tight budget backing up both staff desktops (Windows) and servers (Linux) which have local user account data (but not clear-text passwords, credit cards, or other nasty things like that). Favorite tool or service suggestions would be welcome.

Scott Pack
  • 15,167
  • 5
  • 61
  • 91
nealmcb
  • 20,544
  • 6
  • 69
  • 116
  • +1, but no Windows servers? And this is just backing up data, no DRP/BCP, right? – AviD Jan 05 '11 at 09:19
  • Extra credit for windows servers.... Double extra credit for addressing distaster recover / business continuity best practices :) Tool recommendations appreciated. – nealmcb Jan 06 '11 at 17:28

6 Answers6

18

The biggest gotcha I encounter is still "did you test that you can recover from the backups?" I apologise if I'm teaching grandmother to suck eggs, but I still come across companies that happily write all their data out somewhere and never find out whether they can read it back.

  • +1 all the time. Even with very large global organisations :-) – Rory Alsop Jan 05 '11 at 09:59
  • 3
    Yup. Thankfully, given the modern conveniences of virtualization, this sort of testing is much easier. And people often forget that "security" isn't just about preventing access - it includes ensuring good access to the data by the people/processes that need access. – nealmcb Jan 05 '11 at 13:58
12

Another one which causes more issues than you might expect is providing the backups with sufficient security. I have seen numerous instances where there was no protection of backups aside from being stored in a warehouse. This includes storing unencrypted customer account and password data!

It makes it very easy for attackers - okay, they need to go back to physical attack, but this is a relatively straightforward way to get past all those technical controls that might exist on the live environment.

Best practices for backup are still applicable for small businesses:

Provide the appropriate level of encryption around backups

  • Encrypt everything? easy but time consuming
  • Just encrypt sensitive data? you need to then work out what data

Don't backup data which should not be backed up

Test incremental and major backups regularly

Test gold builds and snapshots (these count as backups too)

Physical security is also essential

  • Locked premises
  • Fire safes
  • Fire extinguishers

Contractual SLA's

  • Who controls your backups?
  • Can you trust them to get them backl to you on a timely basis as required?
Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
  • 7
    Re encryption, don't forget secure backup of encryption keys. Backing up encrypted data, and losing the key, is another classic fwoop. – AviD Jan 05 '11 at 22:25
2

Practice. Backup your home server or box you care little about to the point where you think you can perform a bare metal restore, restore to virtual state, and keep doing things like this. I am also watch patches a lot more for my backup systems as well. PCI laws apply also (I believe) no computer database holding client credit card information to be directly accessible from the internet, I would say be best to make sure backups of the data are not accessible from the internet as well. It also doesn't hurt to learn more than one system (Microsoft Data Protection, Symantec,and CommVault.) Learning these helped me with understanding best way to encrypt files for backing up and restores. Many shops and IT departments from what I have seen encrypt the backups after the fact with a different tool.

Scott Pack
  • 15,167
  • 5
  • 61
  • 91
IrqJD
  • 141
  • 2
2

Many backup solutions will allow you to still use most of a backup if part of the backup is damaged... unless you used a stream cipher for encryption. If your encryption is something added on to your backup package, watch out for that gotcha. In fact, watch out for it even if it is included in your backup package.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
2

If you are talking about desktops, you should have a clean desktop deploy image for recovery, and force storage of all data on the network file server. It shouldn't be hard to store profiles and local settings on the server and all documents for desktops.

Do incremental daily snapshots to a secondary file server. Encrypt offsite backups and either physically move them offsite or backup over a VPN to another secure location. Perhaps you rotate through 4 weekly offsite backups (ie: 4 backups, one each week). Encrypt them each with a different key to limit the damage of losing a given key. Keep a 6 month backup somewhere safe too or quarterly depending on your risk profile.

Bradley Kreider
  • 6,152
  • 2
  • 23
  • 36
1

Make sure that at least one backup is both offsite and not connected to power or internet. At least one backup IMO should be thus hardened against attacks via network and also power surges/lightning.

Also brainstorm about what natural disasters are common to your area when selecting your offsite location(s). You don't want to be hit by something that could take out your main site + all your backup locations.

user1971
  • 783
  • 6
  • 9