backup – Page 4 – Eclipse Systems Knowledge Base

How do I enable the rsync daemon on Linux?

To configure rsync to operate as a daemon (server mode), create a config file, /etc/rsyncd.conf:

vim /etc/rsyncd.conf

Here’s a sample configuration:

uid = root
gid = root
use chroot = yes
[snap]
path = /snap
read only = true

Enable the service to automatically start on boot:

chkconfig rsync on
chkconfig --list rsync

How do I test my backup?

The correct procedure for testing the integrity of a backup — tape or network — is a three-step process that can be completed in part or in whole, depending on what particular function of the backup you are interested in verifying:

Perform a full restore of the tape or network backup to a temporary directory or separate test server. This verifies that the correct restore procedures are documented, detects media errors or problems with the network restore process, and confirms availability of the necessary data files.
Run the UniVerse uvbackup tool against the restored data. This verifies that the database files are in a consistent, unbroken state.
Launch Eclipse and process orders, run reports, etc. to compare the operation of the restored data with behavior in the live database. This verifies that the database’s important files are all available and in a state consistent with one another.

Can ABS CrashPlan be configured to run at a specific time?

There are two methods of scheduling when CrashPlan runs:

“Always”

This is default setting. CrashPlan will always run, and will back up at the interval specified under Settings -> Backup tab -> Backup frequency and versioning.

The benefit to running CrashPlan “always” is that the backup will capture data throughout the day, therefore reducing the amount of data lost if a restore is necessary.

The downside to running CrashPlan “always” is that there is a potential for contention with the snapshot script, because both tools use different types of scheduling logic:

The snapshot script is kicked off from crontab at regular intervals based on a static timeline (ex 12:00 AM, 3:00 AM, 6:00 AM, etc.).
The CrashPlan backups are independently kicked off at regular intervals based on a dynamic timeline (ex 3 hours after the last backup to a particular destination completed).

Since the snapshots are kicked off at a regular interval via crontab, it’s possible that the snapshot could “refresh” itself (ie new snapshots are created) or “expire” (ie fill to capacity) during the CrashPlan backup process, thus invalidating the backup. The longer the CrashPlan backup(s) take, the higher the likelihood of the snapshot becoming invalid during the backup process. To prevent the snapshot script from running during an active CrashPlan backup, the snapshot script automatically stops the CrashPlan service during its operation. Upon completion of the snapshot creation process, the CrashPlan service is started, and the backup schedule is resumed.

An example configuration that has proven to work for many customers is the following:

Set CrashPlan to run every 12 hours. The 12-hour interval between backups has shown to allow sufficient time for both local and remote backups to complete in a variety of configurations.
Set the snapshot script to run at 12:00 AM and 12:00 PM. This ensures that a “point-in-time” representation of your data is available for restore at least twice daily.

“Between specified times”

There is an optional setting that can be configured under Settings -> General tab -> Crashplan will run: -> Between specified times.

The benefit to running CrashPlan “between specified times” is that it allows for the concrete definition of a window of time during which the backup should run. This is useful if there are bandwidth or performance constraints to running CrashPlan backups during business hours. The window should be made large enough to allow the completion of backups to each individual backup destination. The snapshot script should be scheduled to directly before the CrashPlan backup window, and the snapshot volume(s) must be large enough to remain active through the end of the backup window.

The downside to running CrashPlan “between specified times” is that the recovery points for data restoration are often reduced in conjunction with the available backup window. Despite this, the CashPlan agent still has many advantages over a traditional daily tape backup, including increased ease of administrator, archive reliability, security and the ability to backup to multiple destinations.

If you choose to modify the time during which CrashPlan operates, please ensure that the Eclipse snapshot backup script is scheduled via crontab to run prior to the CrashPlan backup window. For more information, see: How do filesystem snapshots work on Linux?

How do I perform a manual ABS CrashPlan backup?

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

Stop the CrashPlan service:

service crashplan stop

Run the snapshot backup script to create new snapshots of the Eclipse filesystems

/bin/save

Start the CrashPlan service:

service crashplan start

To verify the back is running, log into the server’s GUI as root using VNC, DRAC or the local console
Use the CrashPlanDesktop shortcut, or press to open the run dialog box and run the command:

CrashPlanDesktop

If the backup is not currently running, click “Play” button next to the backup job to manually start the backup job.
If the backup button is grayed out because the backup service is not currently scheduled to operate, you’ll need to temporary change the schedule to “Always” in the CrashPlan settings menu.

How do filesystem snapshots work on Linux?

Screencast:

How do I verify the amount of data being backed up by CrashPlan?

Launch the CrashPlan desktop client and open the History tab. Scroll down and look for the most recent the “Completed backup” entries. Here’s an example:

I 09/29/10 03:17PM Completed backup to ABS Online Backup in 12.2 hours: 21,565 files (77.92 GB) backed up, 2.19 GB encrypted and sent @ 15.90 KB/s (Effective rate: 7025.81 KB/s)

In this example:

The backup completed at 3:17 PM on 9/29/10
The backup destination was “ABS Online Backup”
The backup process took 12.2 hours
There were 21,565 files backed up which had a total size of 77.92 GB
There was 2.19 GB of change data compressed, encrypted and sent to the backup destination
The average “real” transfer rate was 15.9 KB/s
The average “effective” transfer rate was 7025.81 KB/s

For more detailed information, see the CrashPlan PRO documentation.

Tag: backup