Просмотр

===1.6.Reliability of Service===
<u>Backup & Restore Policy</u>
*Backups should be made regularly and some backup media should be stored regularly off-site.
*Class 3 backups should be stored in a locked safe. All media must be accounted for. Old tapes must be destroyed, not thrown away.
*A backup policy must exist (documented) for each system or group of systems, containing:
:*When and how are (full or incremental) backups made, where are media stored, for how long?
:*How often are backups made, who is responsible for checking their correct operation?
:*How long are indices kept? Where are they stored? How can they be recovered from archive media?
*A restore policy must also exist, containing:
:*Who is responsible for checking correct operation?
:*A detailed description of what utilities are used how to restore data for all applications. (e.g. OS, database restore mechanisms). 
:*In particular a detailed description of how to restore the Operating System after serious disk or other hardware failures is required. Use of embedded EPROM commands, single user or diagnostic modes (where available) should be documented.
:*The expected restore time for various disaster scenarios should be documented
*Test the restore policy regularly.
<u>Change Management (sw/hw installations or updates)</u> 
*Only system administrators should install or update software on servers. Users may not install software on class  workstations.
*Systems should be cleanly installed according to vendor instructions.
*A change log, detailing all changes to a system should be kept on EVERY server. It is suggested that as a minimum, a simple text file be created (e.g. /etc/mods) containing: Date, sysadmin name, files changed and reason/comment.
*OS installations should include installation of all recommended patches.
*A label containing the following information should be stuck on all machines during installation: Hostname, Machine manufacturer/model, IP address, MAC address, cabling node id (if network topology allows), end of guarantee date and security/helpline telephone number.
*Servers should also have: the server name on all peripherals, disk type/guarantee date/superblocks/configuration, console commands for stopping/rebooting (e.g. special key sequences)
*Only patches from the original sw vendor should be applied. Patches downloaded from public networks (e.g. Internet) should be checked for integrity using a strong hashing mechanism (e.g. MD5). Patches should be pre-tested in a test environment (for at least a few weeks if possible) before being applied to production systems.