Tag: abs

All successful backups of an Eclipse database server, regardless of the backup software being used, require the successful completion of both of the following two, separate processes:

• Prepare: the snapshot process that prepares a point-in-time, frozen “picture” of the database and application files. For an overview of this process, see How do filesystem snapshots work on Linux?
• Capture: the backup software process(es) that take this snapshot data and transfer to any sort of archival media (disk, tape, online vault, etc.)

For ABS customers, a successful backup requires a successful database snapshot and a successful CrashPlan backup running to completion between snapshot intervals. This article will review how to check the status of both processes.

Part 1: Snapshot Verification

First, we must verify that the snapshot process has completed successfully.

Log into the server as root via command line or GUI.

Open the /tmp/snapsave.log via your preferred text editor. For example, using less from the command line:

less /tmp/snapsave.log

Review the log for the following items:

• Date/time the snapshot was created
• Whether or not the snapshot operation was successful, or if any warnings/errors were generated

Because each snapshot volume is of a fixed size, it’s possible for snapshots to run out of room. You may check the current snapshot status using the lvs command and noting the values in the “Snap%” column:

[root@firestorm ~]# lvs
  LV       VG     Attr   LSize  Origin   Snap%  Move Log Copy%  Convert
  eclipse  datavg owi-ao 50.00G                                        
  ereports datavg owi-ao  1.00G                                        
  lvol0    datavg swi-ao  1.00G u2         6.01                        
  lvol1    datavg swi-ao  1.00G eclipse    8.52                        
  lvol2    datavg swi-ao  1.00G ereports   0.00                        
  u2       datavg owi-ao  2.00G                                        
  uvtmp    datavg -wi-ao  4.00G                                        
  backup   rootvg -wi-ao 50.00G                                        
  esupport rootvg -wi-ao 40.00G                                        
  root     rootvg -wi-ao 40.00G                                        
  swap     rootvg -wi-ao  4.00G

If any of these values are 100%, the snapshot became invalid at some point by holding too many changes. Since we’re attempting to verify the backup was successful, we’ll want to note the date/time that the snapshot became invalid, to verify that the CrashPlan process completed prior to the snapshot becoming invalid. The /var/log/messages file contains timestamped entries for all snapshot events, so the following command will show you any relevant snapshot-related messages, including when a snapshot is no longer being monitored:

grep snapshot /var/log/messages

As an alternative to manually checking the snapsave.log file on a daily basis, you may opt to configure your system to automatically email this log to your regular address using the instructions found in How do I forward root’s mail to another address?

Part 2: CrashPlan Verification

Next, we must verify that CrashPlan was able to archive all of the snapshot data successfully between the time the previous snapshot completed and the next one was started (typically 24 hours).

If you prefer using the command line, you may verify the last few most recent backups using the following command:

egrep "Starting|Completed" /usr/local/crashplan/log/history.log.0 | tail

There are a few things to note in this output:

• The backup process should have started after the snapshot was created
• The backup process should have completed before the next snapshot was scheduled to be created, or before the snapshot filled to capacity

If you prefer to use the GUI, this same historical information is visible from the CrashPlan Desktop interface.

View a step-by-step screencast of this process:

• Log into the server’s GUI via VNC, the DRAC, or the local console
• Double-click the CrashPlanDesktop icon to launch the CrashPlan client interface. If there is no shortcut, follow these instructions to create one.
• The CrashPlan GUI opens to the “Backup” dashboard, and the current status of each separate backup job is displayed
  
• For additional information, select the History tab and scroll through the detailed history.