Backup

1
Backup
2
What is Backup?

• Contingency Plans

• The ability to continue with what was given some
  change

Simplest Document
Complete Disaster Recovery
3
What Backup Should be Used?

• There is no single solution for everything
• There are different reasons for Backup
• Precautionary, Reference, Testing and Training
  Purposes

• A Policy put in place to meet your requirements

IT Paranoia
Company Procedures
Industry Standards
Government Regulations
4
Pronto System Options

• Pronto Backup using pronight

• Live to Test Copy

• Various Forms of Output
• Flat File Extraction such as by using proman
• Reports Hard and Soft Copy, XML, Crystal etc
• Exporting to MS Excel
• Using ODBC to export to third party applications
  etc

Oracle Options

• Oracle Offline Backup using ora_cold_backup

• Oracle Online Backup using ora_hot_backup

5
Systems Options

• System Backup

• Replication
• RAID (which includes Mirroring)
• Whole System Replication

• Other contingencies
• UPS
• Maintenance Support

6
Important Factors

• They need to work. Therefore testing required.
• eg Can you perform Disaster Recovery from your
  Backup?

• Determine which option or combination of options
  best suits the requirement. Simple or Complex.

• Prevention is better than a cure.
• eg Use Backup for Testing before committing in a
  Live System.

7
Pronto Backup

• Usually run Nightly via a root cron job.

• Backup is usually controlled by a script
  developed by Pronto which has been customised.
• Customisation may be based upon hardware, file
  structure, desired format and what you want
  backed up.
• That script is PRONTO/lib/pronight
• Modified only by those that understand its
  workings.
• Once operational, make sure that it works.

8
Overview of pronight

• It prepares the Database itself to be backed up

• Determines a list of what is to be backed up

• The data it is dumping comes from
• PRONTO, ORACLE_HOME/dbs, LOGDIR

• This list is used to dump the data in formats
  such as
• cpio, tar, lha etc

• Backup can be output different ways
• Various Tape Devices, Autoloaders etc using
  assorted media.
• Removable Hard Disks.
• Or output to a separate location as part of
  System Backup.

9
Pronto Backup Verification

• The output of the backup cron job is emailed to
  root user.

• A copy of this output is dumped to
  /tmp/pronight.log.
• This file can be used to email the output to
  other users.

10
Pronto Backup Verification cont

• If pronight used cpio to dump to /dev/rmt/0n in
  this case a DLT tape device, it could be verified
  by
• Rewinding the tape mt f /dev/rmt/0n rewind
• Listing tape Contents cpio itcvB lt /dev/rmt/0n

11
Live to Test Copy

• Performs a copy of the Live System. Purposes
  include
• Month or Year End Reference.
• Testing, Training, Problem Solving.
• Precautionary Measure prior to Changes being
  made.

• Running of these scripts may be able to be run
  using options under Backup / Restore data in
  proadmin.

• Names of scripts may vary but generally, there is
  a hard coded script called PRONTO/lbin/live2t
  est
• This in turn may reference PRONTO/bin/procopy
• Or for Oracle users PRONTO/lbin/ora_copy.sh

12
Live to Test Copy Considerations

• You should have a special DBA user setup in
  Pronto with the same configuration as the user
  psd.
• The same Unix permissions.
• The same Pronto access and setup.
• The same Oracle access and permissions if
  applicable.

• Try to ensure that there are no connection drop
  outs.

13
Live to Test Copy Warnings

• Problems may be experienced if the following
  takes place
• A Live to Test Copy be run by a User with
  inadequate setup.
• The connection drops out in the process.

• These problems may occur in Test and Live
  systems
• I/O Errors.
• Problems with Data Entry in some screens.

• These are usually simple enough to resolve.
• Running Live to Test again fixes some issues.
• Other problems may require Oracle fixes etc.

• Be mindful of changes following each Pronto
  Upgrade.

14
Oracle Live to Test Copy
15
Renaming Test Copy

• The Test Copy can be named to something more
  meaning by using the Correct option in
• Maintain Company Details SYS.M032

16
Proman

• Before running an Update SQL etc on a particular
  object, it may be worthwhile to output a copy of
  it to flat file.

• Open proman.
• Select Other
• File copy/conversion.

17
Oracle Offline Backup

• Shuts down the Oracle database before hand.
• The pronight script calls PRONTO/lib/ora_cold_b
  ackup.

• If the database cannot be shutdown, the backup is
  aborted.

18
Oracle Online Backup

• When this is run, the Oracle database is still
  running.
• Some companies may not have the luxury of being
  able to shut down the database completely.
• The pronight script calls PRONTO/lib/ora_hot_ba
  ckup.

• This form of backup relies extensively on the
  Archive Logs.
• They are located under LOGDIR.

19
Tailoring Backup

• If you have a special requirement for a
  particular tablespace to be backed up, this can
  be done.
• Using Oracle for an example, create a copy of the
  relevant script PRONTO/lib/ora__backup.

• One way to do it is the change the script to only
  back up the tablespace company1.
• A WHERE clause could be used in the SQL Query to
  specifically identify the tablespace company1.
• The list of files to be backed up output to
  FILES can be filtered so that only data under
  PRONTO/data/company1.

• The crontab can be modified if necessary.

20
System Backup
/ /var /users /BACKUP
C D
File Server
Windows Server
Pronto Server
/ /var /BACKUP
/pronto /oracle /archives
/BACKUP
21
System Backup Considerations

• Have a Retention Policy in Place. For example
• Daily Keep for at least a month
• Monthly Keep for at least 18 months
• Quarterly Keep for at least 7 years

• Keep an Offsite Backup.
• Adequate Backup to perform Disaster Recovery

• Monitor any Incremental Backups.

22
AMANDA System Backup

• Most Backup Systems provide tools to help you
  locate what you need to recover but vary
• Full GUI, Text based Interface, Combination

• This Case Study uses the AMANDA backup system
  (See www.amanda.org for details)

• Checks can be done prior to backup.
• System Availability, Correct Tape amcheck Daily

23
AMANDA Backup Recovery

• A full file system may be able to be recovered
• cd /temp
• amrestore /dev/rmt/0n cobra /
• gzip -d /temp/cobra._.20060107.0 ufsrestore
  -ivf -

• Or individual files or paths from a particular
  date
• cd /pronto
• amrecover -C Daily -s viper

24
System Backup Recovery

• AMANDA utilises Tools available to an Operating
  System for backup. Not all applications do.
• eg ufsdump, backup, xfsdump.

• This enables data to be recovered once you have a
  functional Operating System available.
• mt f /dev/rmt/0n rewind
• mt f /dev/rmt/0n fsf 14
• dd if/dev/rmt/0n bs32k skip1 gzip -d
  ufsrestore -ivf -

25
Finding System Backup Recovery

• To perform Level 0 Backup Recovery you may need
  
• Level of Backup, Tape Name, Location on Tape.
• amadmin Daily find cobra /

• Note Such commands may not be available to you
  at first during Disaster Recovery. This should
  be recorded.

26
Pronto Backup via System Backup

• PROS
• It is very transparent as to what is being backed
  up.
• If the problem is realised on the same day, there
  is no need to go back to tape.
• Interactive Backup System tools can be used.

• CONS
• You are at the mercy of the System Backup.
• System Backup may need to be delayed to cater for
  it.

27
RAID

• Redundant Array of Independent Disks

• RAID can be controlled by Hardware or Software

• Commonly used RAID configurations are
• RAID 1 Mirroring. Data blocks from one disk
  are copied to another. If a disk fails, its
  Mirror kicks in.
• RAID 5 Each disk distributes parity blocks to
  the others. If a disk fails, the data is rebuilt
  from the parity blocks from the others.
• RAID 6 Same as RAID 5, except each disk
  distributes 2 parity blocks to the others.

28
Mirror Checking - metastat
29
Checking Mirrors - metadb

• Tip Use a cron job to run these checks.

30
Disaster Recovery Preparation

• Keep all relevant Work Instructions updated and
  should include such information as
• Details of how disks are partitioned etc.
• What your environment variables are.
• Mirror handling.

• AIX mksysb, Solaris jumpstart, Linux -
  kickstart

31
Disaster Recovery Preparation cont

• Ensure that the System Installation media is
  available.

• Necessary root password is known etc.

• Adequate backup is available to perform the
  Disaster Recovery.
• Remember Your actual Backup Application may not
  be available at first so precautions should be
  made.

32
Before Pronto Restore

• An operational server is required. Preferably
  the same or as close to the original server.

• Obtain a temporary license key from Pronto.

• Check that the Pronto Environments have been set
  up correctly
• PRONTO, BMS, ORACLE_HOME, LOGDIR, CUS

33
Pronto Restore

• Restore files from the following where
  applicable
• PRONTO, ORACLE_HOME, LOGDIR

• Start the Pronto Database
• Issue the command PRONTO/bin/install
• Enter the temporary license key when prompted.

Oracle dbstart

• As the oracle user
• Issue the command dbstart
• When prompted as to whether this is a first time
  install, Select N for No

34
Oracle SQLplus
Note The following is a rundown of commands
used during a May 2005 Pronto Restore Test. It
may not work for all systems. Please do your own
tests.

• If the dbstart command fails, it may be necessary
  to start SQLplus via
• su oracle c ORACLE_HOME/bin/sqlplus / as
  sysdba
• Issue the command shutdown immediate
• This may result in errors.
• Issue the command recover database

• Similar messages appear as per the dbstart
  command.
• Issue the command again recover database

35
Oracle SQLplus cont

• Files under LOGDIR will be processed in turn
• ORCL_arch_1_?????.arc

• Once this has finished
• Issue the command alter database open

• This completes the SQLplus startup process.
• Shutdown the database using shutdown immediate

• As the oracle user
• Issue the command dbstart

• Log into Pronto as normal to test functionality.

36
Things to Remember

• There are different forms of backup.
• Choose those which are most appropriate to the
  circumstance.
• Its OK to be paranoid but keep it within reason.

• Ensure Work Instructions are up to scratch.
• Saves a lot of unnecessary torture under pressure.

• Perform Testing when you can.

• Automate as much as you can. Work smarter not
  harder.
• Reduces the Day to Day demand on your time.

• Know your own Limitations.
• Do not be afraid to seek assistance if needed.