«

»

Sep 03

Your Top 10 Security Steps to Protect Your Data, Part 7

6. Back up databases and other important files (continued from Part 6)
Also, network administrators should assess risks to data systems and business-critical functions. For example, consider:
•Theft of data or theft of proprietary intellectual property.
•Disruption, theft, or damage to network infrastructure such as servers, networks, data storage, or data backup storage. Damage can be caused by password hackers or by other types of malicious sabotage and destruction. It is a sad fact that most incidents originate from within the organization.
•Disruption or damage to the organization infrastructure such as building fires, environmental or biological hazards, floods, and so on. We’ve seen some incredible natural disasters in the past couple of years, in the most unlikely places, so never think “It can’t happen here.”
•Disruption or damage to the public infrastructure, including electrical power, telecommunications (voice and data), transportation grids (roadways, buses, trains) caused by environmental conditions, or severe weather such as tornadoes or floods. After Hurricane Wilma in Florida (the one just after Katrina) there was no power in some areas for almost 3 weeks. Our colleagues down there had a back-up generator, but got to the point where they were running out of fuel because gas pumps run on electricity as well. What would three weeks of no power do to your business?
In the event of a server failure, such as an unexpected loss of power, hard drive failure, or software failure, use the backup files. Any system failure causing the database to shut down inappropriately can result in corrupted files if cached data was not written to disk and the files were not closed properly. Even if the files re-open and go through a consistency check or recovery, corruption might be buried in the file.
Use the  file recovery feature of your database when a file is closed inappropriately and the data since the last backup must be recovered. Recovery creates a new file with a name different than the original file because it is not intended to replace the file. It is an aggressive process which might remove layouts, scripts, etc. in order to return the most data possible. The data should be exported from the recovered file and imported into a clean backup of the original database file.
Because recovery can take a long time, make local backups at an interval relating to the amount of data that could be lost.

Leave a Reply