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.