Potential Disasters
Being prepared for potential disasters can help to reduce downtime and stress levels
A data protection plan that includes a backup and restore strategy can minimize the negative impact when damage occurs. Preventative measures can also effectively reduce the frequency of occurrence and impact of each threat.
A data protection plan that includes a backup and restore strategy can minimize the negative impact when damage occurs. Preventative measures can also effectively reduce the frequency of occurrence and impact of each threat.
Causes of Data Loss
Hardware Malfunction: Hardware and system malfunctions are the primary reason for data loss. These include failures such as disk head crashes, disk controller failures, network connectivity or component failures, off-line power supply failures, and cooling fan failures. Fortunately, technological advances in recent years have made component redundancy. For instance, Redundant Array of Independent Disks (RAID) solutions dramatically reduce the likelihood of data loss because of disk-related failures. Redundant power supplies and cooling fans provide fault-tolerant protection if the primary component fails.
Human Error: Another substantial threat to data integrity is the risk posed by people. This type of damage occurs in two forms: intentional and unintentional. Individuals or groups can inflict deliberate harm, with malice as the end goal. The best defense against this type of threat is a very aggressive security program that includes appropriate segregation of data with access granted on an as-needed basis. Accidental data casualties also can be dramatically reduced by a rigorous policy of appropriate access management. For personnel who can access and modify sensitive data, training is often the best preventative measure against unintentional loss.
Software Corruption: Hardware can and will fail, and the complex software systems produced today will contain defects, thereby instigating some forms of data corruption. The most powerful defense against data loss caused by software defects is a suitable backup schedule.
Computer Viruses: In recent years, worms and viruses have increased in number and become more sophisticated. Even simple programs written with destructive intent can inflict very costly damage on unprotected systems. Fortunately, most enterprise-quality antivirus packages provide excellent protection against the majority of viruses and worms. Data protection plans should include comprehensive information about viruses and clear user instructions using and updating the antiviral agents on their client machines.
Natural Disasters: Temporary data loss has many causes, but the least common—natural disasters—gets much of the attention. Hurricanes, tornadoes, fires, and floods can wipe out entire data centres. Two ways to protect against such catastrophic loss are to store backups in safe, off-site locations, and to maintain some degree —hot, warm, or cold—of recovery-site readiness.
There will be times when you will need to perform a restoration and recovery. As a System Administrator, you hope this will never happen, but the reality is, it could happen at any time. With a good backup and a way to recover the transactions that were not in the backup, the task becomes a procedure and will reduce stress levels during a critical time
Human Error: Another substantial threat to data integrity is the risk posed by people. This type of damage occurs in two forms: intentional and unintentional. Individuals or groups can inflict deliberate harm, with malice as the end goal. The best defense against this type of threat is a very aggressive security program that includes appropriate segregation of data with access granted on an as-needed basis. Accidental data casualties also can be dramatically reduced by a rigorous policy of appropriate access management. For personnel who can access and modify sensitive data, training is often the best preventative measure against unintentional loss.
Software Corruption: Hardware can and will fail, and the complex software systems produced today will contain defects, thereby instigating some forms of data corruption. The most powerful defense against data loss caused by software defects is a suitable backup schedule.
Computer Viruses: In recent years, worms and viruses have increased in number and become more sophisticated. Even simple programs written with destructive intent can inflict very costly damage on unprotected systems. Fortunately, most enterprise-quality antivirus packages provide excellent protection against the majority of viruses and worms. Data protection plans should include comprehensive information about viruses and clear user instructions using and updating the antiviral agents on their client machines.
Natural Disasters: Temporary data loss has many causes, but the least common—natural disasters—gets much of the attention. Hurricanes, tornadoes, fires, and floods can wipe out entire data centres. Two ways to protect against such catastrophic loss are to store backups in safe, off-site locations, and to maintain some degree —hot, warm, or cold—of recovery-site readiness.
There will be times when you will need to perform a restoration and recovery. As a System Administrator, you hope this will never happen, but the reality is, it could happen at any time. With a good backup and a way to recover the transactions that were not in the backup, the task becomes a procedure and will reduce stress levels during a critical time
There are 2 processes to rescue data in the event of a disaster.
Restore: obtaining your last backup and getting your database back to the condition it was in when the backup was made. This process involves restoring SQL backups
Recovery: getting to the point where the disaster happened. This process involves recovering transactions from the Fourth Shift archive file usually found in \Mfgsys\Archive.fil. The process depends on whether the archive file can be salvaged from the disaster if it cannot then data may be lost
Restore: obtaining your last backup and getting your database back to the condition it was in when the backup was made. This process involves restoring SQL backups
Recovery: getting to the point where the disaster happened. This process involves recovering transactions from the Fourth Shift archive file usually found in \Mfgsys\Archive.fil. The process depends on whether the archive file can be salvaged from the disaster if it cannot then data may be lost
Full System Recovery
Typically a full database backup would be used if the physical disk where Fourth Shift is located has been damaged. You will need to restore the last Fourth Shift backup and the Transaction log backups.
Use the following process:
Verify that no other users are logged into Fourth Shift
Stop the Fin and Main database services
Open SQL Server Enterprise Manager and select the Fourth Shift database right click and select all tasks followed by restore database
Use the following process:
Verify that no other users are logged into Fourth Shift
Stop the Fin and Main database services
Open SQL Server Enterprise Manager and select the Fourth Shift database right click and select all tasks followed by restore database
Click on the option tab
Set leave database non-operational to able to restore additional transaction logs. Make sure force restore is ticked and press OK
Set leave database non-operational to able to restore additional transaction logs. Make sure force restore is ticked and press OK
Full back restore is now complete ready for transactional log backups. To restore transactional log backups repeat the process selecting restore database but this time, on the general tab, choose transaction log, and then go and get the transaction log backup using select devices
On the options tab you do not select option to force restore over existing database. If this is the last transaction log, then you do need to select leave database operational for all other transaction log backups set Leave database non-operational
Recovery Transaction Replay(RCVR)
If the transactional log backups are completed every hour it is possible that your missing transaction up to 59 minutes ago. These transactions can be recovered from the Fourth Shift Archive file which is the Fourth Shift transaction log text file. Transactions can be recovered using a batch execution task(BEXE) called recovery replay(RCVR).
Some transactions can't be recovered because they are not written the Archive file:
TMPT(Template Maintenance)
CLDR(Shop Calendar Maintenance)
APCF(A/P Configuration)
APCW(A/P Payment Processing)
APTP(A/P 1099 Processing)
ARCF(A/R Configuration)
CNFG(System Installation Setup)
EDCF(EDI Configuration)
GLCF(G/L Configuration)
GLCO(G/L Consolidation Process)
GLHP(G/L History Process)
LEXP(Lot Expiration/Retest Evaluation)
PASS(Password Maintenance)
NOTE: When recovering transactions you need to be careful with the Modcom files. Due to recovery transactions being repeated into Modcom files. Ensure all duplicate transactions are cleared up from the Modcom files after recovery.
Some transactions can't be recovered because they are not written the Archive file:
TMPT(Template Maintenance)
CLDR(Shop Calendar Maintenance)
APCF(A/P Configuration)
APCW(A/P Payment Processing)
APTP(A/P 1099 Processing)
ARCF(A/R Configuration)
CNFG(System Installation Setup)
EDCF(EDI Configuration)
GLCF(G/L Configuration)
GLCO(G/L Consolidation Process)
GLHP(G/L History Process)
LEXP(Lot Expiration/Retest Evaluation)
PASS(Password Maintenance)
NOTE: When recovering transactions you need to be careful with the Modcom files. Due to recovery transactions being repeated into Modcom files. Ensure all duplicate transactions are cleared up from the Modcom files after recovery.
- Rename Archive.fil and place in safe place. The renamed Archive file to recover is usually called RCVR.FIL
- The renamed Archive file and original \Mfgsys\Archive.fil will need to be edited to delete transactions prior to last SQL restore
- Run the ARCREORG.EXE process found in of Fourth Shift environment. Some Fourth Shift transactions produce multiple interdependent archive records for one transaction. For example, the G/L distribution screen is used after entering a cash receipt on the A/R Cash Deposit(ARCD) screen. In a multi-user environment these transactions are not necessarily recorded contiguously in the Archive file.ARCREORG.EXE is a Fourth Shift utility that is used to reorganize the Archive file so that interdependent archive records are contiguous
- Use the batch process setup(BSET) screen to set up a batch process containing the Transaction Replay(RCVR) task.Use the I parameter to define the name and location of your recovery file: \Mfgsys\Rvcr.fil. Consider using the VS S paratmeters to view transaction during recovery and to step through them which enables pressing of the space bar initially to ensure all is well and then pressing 'C' to continue with the rest of the restore
- Fourth Shift RCVR task(Press F3 on batch execution task for additional help)
- Rename archive file to recover
- I – name of file to recover default folder \mfgsys
- F9...9 Z9..9 from and to records to recover
- E9 Error level
- L- Log file name
- P R999 U999- Looping recovery
- VX S-View mode and step through
- Review the recovery log file for potential problems usually found at \Mfgsys\Rcvr.err
Disaster Scenarios
It is a good idea to carry out mock disasters with a pilot Fourth Shif™t environment so that you are prepared should they occur. Here are typical Fourth Shift disaster scenarios. How would you deal with these disasters?
Fourth Shift stopped during overnight batch execution process
Fourth Shift database corruption at 2:40PM in the afternoon because of a malicious user
Fourth Shift server mysteriously blown up
Fourth Shift stopped during overnight batch execution process
Fourth Shift database corruption at 2:40PM in the afternoon because of a malicious user
Fourth Shift server mysteriously blown up
Fourth Shift Recovery Advanced Topics
|
Get help with your Fourth Shift disaster Recovery requirements
|
Fourth Shift Risk Assessment Business Data Protection Planning Business Contingency Plan Restoring from a different Fourth Shift environment |