Backups: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
No edit summary
Line 40: Line 40:
==Additional Info Required==
==Additional Info Required==
* '''''on what day does this happen  
* '''''on what day does this happen  
* '''''where is the data sent to  
* '''''where is the data sent to  
* '''''and where is the actual batch file
* '''''and where is the actual batch file
* '''''who does this if Pagasa is not here'''''
* '''''who does this if Pagasa is not here'''''


[[Category:stubs]]
[[Category:stubs]]
[[Category:Data Processing]]
[[Category:IT Instructions]]
[[Category:IT Instructions]]

Revision as of 05:40, 2008 July 25

We are using two-tier backup schemes during data collection and again for the primary data repository.

PDA Backup

The data on the PDA is to be backed up manually using Sprite Backup at least before each sync, but preferrably more often. Additionally, each sync generates a copy in the backup directory of the given location's directory under L_Handbase on the regional server, e.g.

  • \\sbghnwfs0102\NSSVOL1\shared\ICU_DATA_COLLECTION\L_HanDBase\GRA_MICU\backup

This location will keep the copies for the most recent ten syncs. The data for older syncs is discarded. Since the 10 sync copies are stored on the regional server, this provides off-site backup.

Primary Data Repository Backup

The primary data repository is quasi backed up because copies of it always exist on at least all the PCs in the home office at HSC. In addition to this, Pagasa runs a batch file weekly that copies the data to the network.

Previous Docu as of May 5 2006 needs updating

Backups for the CCMDB Program

Currently

  • CCMDB data is stored locally on the 4 PCs in the office on shared drives
  • Pagasa updates it to these locations when new data is available.
  • Everyone has to be logged in and the directories must be shared for Pagasa to be able to copy files there
  • Manual/Batch backup to the HSC SAN

Problem

  • There are PHIA concerns with us taking the backups off-site. However, not taking a backup off-site risks loosing data.
  • According to IT Policies patient data should not be stored locally on PCs due to security concerns
  • According to IT we will soon not be able to use shared folders on PCs any more.
  • If we can’t use shared folders any more, we will have to change our data management process from a “push” by Pagasa to a “pull” from the network by everyone prior to running the program. This would need to be set up, and would be time consuming every time the program is used.
  • Pagasa can only “push” files to people who are logged on
  • Data at the data collector PCs is not being updated at all

Recommendation

  • If the program could be changed so that the location from which to pull data is variable, we could put the data on the SAN. This way
  • we would be in compliance having it off the PC
  • we could have automatic off-site backups through the IT backup policy
  • even without the backup policy, the data would probably be on the regional server at SBGH, and therefore even the live data would be off-site
  • we would be able to keep the local installs on data collectors PCs up-to-date
  • we would be able to continue to use a 1-step process to disseminate the data
  • we would be able to eliminate local shares
  • If we don’t want to trust IT with the backups, we could have back-up to a memory stick that could be kept in Trish’s office, detached from the PC to be safe from power surges and viruses. Since the server is at SBGH this should suffice as an off-site backup.

Additional Info Required

  • on what day does this happen


  • where is the data sent to


  • and where is the actual batch file


  • who does this if Pagasa is not here