Backing up data before leaving work at the end of December

Some Y2K problems in early January may not be apparent until after new data has been entered or data processing has occurred. In such cases, data may be incorrectly changed or databases are corrupted. Or if Y2K problems may prevent an application from running. To minimize problems with damaged data or corrupted databases, or problems moving data to another system, it is critical to make a backup before the problem occurs.

Data (and document) backups should be done routinely, of course. But too many people don't routinely do this because it's extra work. The end of December is a good time to make an exception to the "maybe sometime later" approach to backups.

To deal with possible Y2K problems, a full backup (of software programs as well as data ) isn't necessary. Nor is putting the backup media (diskettes, tape cartridges, etc.) in a separate location. In fact, unlike most data backups, it's okay to simply copy the data/documents to another directory on the same hard drive. The sole objective is to have a copy of the data/documents somewhere where it won't be processed by application software in January. That way, if the application software mangles the data, the backup copy (unprocessed) is still available*.

Exactly what needs to be backed up (copied)? All databases in use, and any important spreadsheet documents certainly should be. So should any "pure data" files created by specialized applications. On the other hand, word processing documents do not need to be, as long as you have checked the web site of the vendor to confirm that there are no Y2K problems with the word processing software. Similarly, "mailboxes" (documents containing e-mail messages) don't need to be backed up, again assuming the vendor says that the e-mail software is Y2K compliant.

One final difference from regular backups is suggested for late December. If the application involved is very old or unusual (custom-written), it would be a very good idea to export the data from the application in addition to making a copy. Exporting data changes its format into something that can be easily read by (imported into) other applications, such as such as comma-delimited data. And if the application doesn't have an export option, there is even more reason to try to get a copy of the data into a format that be read by other programs. (If the application has Y2K problems and won't run, and the data can't be read by any other application, then what is Plan B?)

* If an application mangles your data or a document, and you have a backup copy (congratulations!), don't try again with the backup copy. Make another copy of the original backed up data/document, and use the copy of the copy. Never use the only undamaged document/file or data - if it gets mangled, then you're really in trouble.

Return to the main Rollover Planning page

Contact for questions and comments about this page:
johnb@uclink4.berkeley.edu
Web Administrator: salas@uclink4.berkeley.edu
Last Updated Tuesday, 29-Feb-2000 11:53:21 PST
Berkeley Campus Home page
Copyright Regents of the University of California, 1999
Disclaimer: The University assumes no liability if the information on this page is used for other than University purposes.