Tag: linux

How do I check the status of my ABS backup on my Linux server?

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.

How do I schedule a cron job in Linux?

To schedule a cron job, type the following command at the UNIX / Linux shell prompt to edit the crontab file:

 crontab -e

The format for cronjobs is:

+---------------- minute (0 - 59)
 |  +------------- hour (0 - 23)
 |  |  +---------- day of month (1 - 31)
 |  |  |  +------- month (1 - 12)
 |  |  |  |  +---- day of week (0 - 6) (Sunday=0 or 7)
 |  |  |  |  |
 *  *  *  *  *  command to be executed

How do I set the IP address on my Linux server?

To set the IP address via the GUI:

To set the IP address via the command line:

Set the default gateway:

vim /etc/sysconfig/network

Change the GATEWAY line, save and quit

Set the IP address and network mask:

vim /etc/sysconfig/network-scripts/ifcfg-eth0

Change the IPADDR, GATEWAY and NETMASK lines, save and quit

 

Can I create a mksysb system backup on my Linux server?

While there is no direct equivalent of AIX’s mksysb utility to create bootable recovery media built into Red Hat Enterprise Linux, there are a number of commercial and open-source packages available that will be able to create system image backups.

In the event of a catastrophic system failure, our standard procedure is to perform a clean installation of the OS, install all updates, restore OS configuration files, and restore the database. While typically not as fast as an image-based restore, this process can be completed in a relatively short time (typically 2-4 hours), works on all any hardware, and ensures that your system is brought up to the latest build specifications.

References:

How often should I update my Red Hat Enterprise Linux server?

We recommend that you install Red Hat Enterprise Linux updates on a regular basis, as they are intended to resolve bugs and fix security issues. How often you choose to install updates is up to you, but we would advise installing updates at least once a month.

As always, we recommend you perform a full system backup before installing any software or making hardware changes.

In most cases, installing Red Hat Enterprise Linux (RHEL) software updates will not impact Eclipse. The base software components that make up the core Eclipse package (UniVerse, JBoss, VSIFAX, etc.) are all installed and maintained separately from RHEL’s rpm software update mechanisms. These updates do have the ability to impact certain OS components used by Eclipse and various companion products (telnet-server, sendmail, postfix, vsftpd, samba, etc.), but the system is configured in such a way to minimize the impact of changes to these components.

Eclipse performs validation testing for each major release of the OS (RHEL 6, RHEL 7, etc.), and our server compatibility page will reflect the latest supported version(s) of the operating system. If we notice any issues resulting from a recent release of an OS package, our first response will be to resolve the problem directly with the vendor. If the software change necessitates changes to our software or configuration, we will provide workarounds as necessary for our existing customers and integrate the fix(es) into the current release of Eclipse.