Fax on Demand

Eclipse recommends Esker’s Fax on Demand service for outbound faxing from Eclipse. ((Incoming faxes to Eclipse are not supported. Please use the manual procedure for uploading logos and append documents.))

What is Fax on Demand?

Fax on Demand is an Internet-based faxing service that doesn’t require any modem hardware or fax lines. Your faxes are sent via the Internet to Esker’s data centers, where they are transmitted to the recipient.

What are the benefits to using Fax on Demand?

The primary benefits are:

  • No hardware requirements, which is perfect for virtual machines and DR scenarios
  • No maintenance required, because there is no hardware to fail or fax lines to troubleshoot
  • Higher quality and reliability, because Esker uses enterprise-grade fax technology, not analog modems
  • Better scalability, so batches of faxes don’t back up the queue for hours or days

How do I receive a quote for Fax on Demand?

To receive pricing, you will first need to email a report of your fax history to Chris Graves at Esker, so that they can estimate your fax volume and provide an appropriate quote. Here are instructions for generating and sending a report to yourself that you can then forward to Esker.

Generating a fax report on AIX

Run the following commands on your AIX server, replacing the example email address with yours:

vfxolog -F csv -h on -U vsifax > /esupport/olog-output.csv
uuencode /esupport/olog-output.csv olog-output.csv | mailx -s "`hostname` Fax Report" email@company.com

Generating a fax report on Linux

Run the following commands on your Linux server, replacing the example email address with yours:

vfxolog -F csv -h on -U vsifax > /esupport/olog-output.csv
echo "" | mutt -a /esupport/olog-output.csv -s "`hostname` Fax Report" -- email@company.com

How do I enable Fax on Demand?

Please follow these instructions for enabling your new Fax on Demand account.

How do I restore files from my ABS backup?

To restore a file or folder from ABS using CrashPlan:

  • If you are restoring to a temporary directory (recommended, create a directory called /esupport/restore
  • Launch CrashPlan Desktop (see also How do I launch the CrashPlan PRO administration software on my Linux server?)
  • Select the Restore tab
  • Select the file/folder to be restored from the “explorer” interface
  • Select the “arrow” to expand all available versions of the file/folder
  • Select the file/folder version you wish to be restored
  • Set the destination to “a folder (/esupport/restore)”
  • Select Restore

 

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 is my PostgreSQL database being backed up?

PostgreSQL is a secondary database used by many of our newer products, including Job Management.

The default method of backing up the postgresql database is by dumping the entire database to an archive file that is captured as part of the regular Eclipse database backup. On Linux, the backup script is located at /u2/pgsql/pgsql_backup by default. On AIX, the backup script is located at /u2/pgsql/bin/backup.sh by default.

This backup script is scheduled to run daily via crontab. On Linux, this is accomplished via a symlink in /etc/cron.daily:

ln -s /u2/pgsql/pgsql_backup /etc/cron.daily/pgsql_backup

On AIX, this is accomplished via a crontab entry similar to the following:

0 0 * * * /u2/pgsql/bin/backup.sh  >/dev/null 2>&1

Which directories should I backup on my Eclipse servers?

The following directories contain the most critical files necessary to recover your Eclipse systems:

  • Database server (AIX, RHEL):
    • /u2 (contains your Eclipse database, UniVerse, JBoss and VSIFAX)
    • /snap/u2 (if using snapshots, this contains the same data as above, but frozen in time)
    • /etc (contains your operating system configuration files)
    • /home (contains your users’ home directories)
    • /usr/spool/uv (contains your legacy UniVerse printer configuration files)
  • Forms server (Windows):
    • C:\Program Files\EclipseForms (contains your Eclipse Forms software)
    • C:\Users\All Users\Application Data\EclipseForms (contains your Eclipse Forms configuration files)
  • Internet Gateway (IGATE) server (Windows):
    • All shared directories containing Eclipse web sites (ex IIS shared directories, etc.)
  • Imaging server (Windows):
    • All shared directories containing Eclipse file shares (ex image attachments, signature scans, etc.)

The UniVerse database must be stopped or suspended during backup to ensure data consistency. The standard Eclipse backup scripts have been modified to use snapshots to allow backups to take place on active systems.

While backing up the directories below should be minimally sufficient to recreate your system in the event of a disaster, backing up the entire system is always recommended when possible. By backing up the entire system, you protect against the loss of miscellaneous files or those inadvertently placed outside of their standard locations.