articleBacking up & Recovering up.time

Article Contents


Overview

Performing regular backups of your up.time DataStore is a highly recommended practice. The DataStore is the up.time backbone and holds all configuration information and historical performance data. This article outlines five common methods for backing up your DataStore.

Note that these backup methods are intended for a single Monitoring Station. Never attempt to merge two or more Monitoring Station configurations in a single database.


Option 1: Creating a tar or zip Archive

One backup option is to regularly create tar or zip archives of your /datastore directory. This is the most straightforward method but requires up.time to be stopped during the backup period.

To use this method, simply include the /datastore directory in the tar/zip archive. If you need to recover your DataStore from a tar/zip archive, ensure that all up.time services are stopped and that you delete the existing /datastore files before extracting your archive.

  1. Stop the up.time services.

    On a Windows platform, stop the following Windows services in the specified order:

    net stop "up.time Web Server"
    net stop "up.time Data Collector"
    net stop "up.time Data Store"


    On a UNIX platform, run the following commands in the specified order to stop the up.time services:

    # /etc/init.d/uptime_httpd stop
    # /etc/init.d/uptime_core stop
    # /etc/init.d/uptime_datastore stop

  2. Archive the datastore directory.

    On a Windows system:

    1. Locate the up.time install directory (default C:\Program Files\uptime software\up.time).
    2. Archive the \datastore directory (using an archiving tool such as Winzip).
    3. Move the zip archive to another system or drive.

    On a Unix system, enter the following commands:

    # cd /usr/local/uptime OR cd /opt/uptime
    (depending on the OS)
    # tar -cvf uptime_backup.tar datastore
    # gzip uptime_backup.tar

  3. Restart the up.time services.

    On a Windows platform, start the following Windows services in the specified order:

    net start "up.time Data Store"
    net start "up.time Data Collector"
    net start "up.time Web Server"


    On a UNIX platform, run the following commands in the specified order to start the up.time services:

    # /etc/init.d/uptime_datastore start
    # /etc/init.d/uptime_core start
    # /etc/init.d/uptime_httpd start


Option 2: Using the mysqldump Tool

mysqldump is a free utility included with the standard up.time MySQL database. This tool will export DataStore contents into a human readable .sql file that can later be used to recreate your DataStore. The commands below detail how to export both configuration and performance data using mysqldump.

NOTE: The following sample commands are provided with the assumption that you are executing them from the up.time installation directory and that the default database access options have not been changed. If any parameters have changed, refer to your uptime.conf file for the correct port, user, password and database access information.


The standard format for the mysqldump command is as follows:

mysqldump --single-transaction -u[username] -p[password] -P[port #] --protocol=tcp [dbname]


By adding > mybackup.sql to the commands below, all mysqldump data will be directed to the mybackup.sql file. The mybackup.sql file name should be changed to a date-stamped file name for easy reference.

Exporting Your Entire DataStore

mysql/bin/mysqldump --single-transaction -uuptime -puptime -P3308 --protocol=TCP uptime > mybackup.sql


Note: The [dbname] variable may be uptime_v4 if your database was created in up.time 4.


Exporting Only Your Configuration Information

mysql/bin/mysqldump -uuptime -puptime -P3308 --protocol=tcp
--ignore-table=uptime.erdc_decimal_data
--ignore-table=uptime.erdc_int_data
--ignore-table=uptime.erdc_string_data
--ignore-table=uptime.ranged_object_value
--ignore-table=uptime.performance_aggregate
--ignore-table=uptime.performance_cpu
--ignore-table=uptime.performance_disk
--ignore-table=uptime.performance_esx3_workload
--ignore-table=uptime.performance_fscap
--ignore-table=uptime.performance_lpar_workload
--ignore-table=uptime.performance_network
--ignore-table=uptime.performance_nrm
--ignore-table=uptime.performance_psinfo
--ignore-table=uptime.performance_sample
--ignore-table=uptime.performance_vxvol
--ignore-table=uptime.performance_who
--ignore-table=uptime.archive_delenda
uptime > mybackup.sql


Exporting Only Your Historical Performance Data

mysql/bin/mysqldump -uuptime -puptime -P3308 --protocol=tcp uptime
performance_aggregate
performance_cpu
performance_disk
performance_esx3_workload
performance_fscap
performance_lpar_workload
performance_network
performance_nrm
performance_psinfo
performance_sample
performance_vxvol
performance_who
erdc_decimal_data
erdc_int_data
erdc_string_data > mybackup.sql


Importing Your Backup Data

NOTE: Before importing data, you must stop the up.time services (see steps outlined in the Creating a tar or zip Archive section).


To import your backup data, run the following command:

mysql/bin/mysql -q -f -u uptime -puptime -P3308 --protocol=tcp uptime < mybackup.sql


This process will attempt to insert any non-duplicate data that is found in your mybackup.sql file. If you need to rebuild your database from scratch, run the resetdb utility before importing your backup file. This utility will erase ALL data in your existing DataStore; be absolutely sure that a full backup recovery is your best option before running this command.

resetdb really --nodata


Option 3: MySQL Replication

MySQL replication is the most complex backup method but is the most powerful for quick recovery. MySQL's built-in replication feature will maintain a completely up-to-date copy of your DataStore on another database instance (on the local system or a secondary server). This copy can be quickly set up to act as the primary DataStore in the event of a failure, or can be easily copied from the replication server to the primary server in the event of an outage.

Information on starting replication can be found at:


Option 4: Oracle Data Pump

If your DataStore is running on Oracle, you can use the Data Pump utility to export data from an Oracle database. Refer to the Oracle database utilities page for more information:


Option 5:SQL Server Backup

If your DataStore is running on Microsoft SQL Server, you can use the SQL Backup tool to export data. Refer to the Microsoft Developer Network for more information:


Other Files to Backup

The following files are not part of the DataStore but should also be backed up on a regular basis, especially if they have been modified or tuned.

  • <uptime_dir>/uptime.conf
  • <uptime_dir>/license.dat
  • <uptime_dir>/wrapper.conf (Windows OS)
  • <uptime_dir>/uptime.lax (Unix OS)
  • <uptime_dir>/apache/conf/httpd.conf

Related Articles


'Default up.time data store' monitor crit after adding a vCenter ...

RatingViews
article

As part of the initial install of up.time, the Monitoring Station itself is setup as an element within up.time. This sample element is initially setup to use localhost as it's hostname, along...

By: uptime Support | Date Created: 3-8-2013 | Last Modified: 3-8-2013 | Index: 592

  2561

Integrating up.time NetFlow with up.time

RatingViews
article

Learn how to configure up.time to point to your Scrutinizer instance to enable click-through graphing, as well as an integrated Scrutinizer view from Global Scan.

By: uptime Support | Date Created: 7-8-2010 | Last Modified: 2-8-2013 | Index: 459

  5206

Monitoring WebSphere with up.time

RatingViews
article

Use up.time to monitor the performance and health of Java applications running on WebSphere servers.

By: uptime Support | Date Created: 12-20-2006 | Last Modified: 7-26-2011 | Index: 108

  6482

The up.time Data Collector is unavailable

RatingViews
article

By: uptime Support | Date Created: 6-9-2006 | Last Modified: 10-17-2013 | Index: 077

  5716

Resolving JVM_BIND Errors in up.time

RatingViews
article

By: uptime Support | Date Created: 6-7-2006 | Last Modified: 8-9-2011 | Index: 075

  9072

User Comments



Subject: Backup using snapshots

From: Mahesh Tailor
Date: 11-16-2006

Comment: Our datastore is around 11GB and growing. Using the methods outlined in the How to Backup Uptime document, we were experiencing longer and longer durations for performing the backup.



To shorten the time, we moved our datastore to an NFS mounted directory presented from a NetApp Appliance. We stop the Up.Time4 processes, create a snapshot of the datastore, and then restart the Up.Time4 processes. The backup which used to take about 35 minutes now takes less than 20 seconds.



To test the snapshot backup, we stopped the Up.Time4 processes, restored a previous snapshot and then started the Up.Time4 processes. All data was there as of the snapshot time.



Here's the script we use to create and manage our snapshots [from our Linux server].



=================================================



#!/usr/bin/ksh



/etc/init.d/uptime4_datastore stop

/etc/init.d/uptime4_httpd stop

/etc/init.d/uptime4_core stop



if [[ -d /usr/local/uptime4/datastore/.snapshot/uptsnap.4 ]]

then

rsh nas.ourco.com snap delete nfsshare uptsnap.4

rsh nas.ourco.com snap rename nfsshare uptsnap.3 uptsnap.4

rsh nas.ourco.com snap rename nfsshare uptsnap.2 uptsnap.3

rsh nas.ourco.com snap rename nfsshare uptsnap.1 uptsnap.2

fi



rsh nas.ourco.com snap create nfsshare uptsnap.1



/etc/init.d/uptime4_datastore start

/etc/init.d/uptime4_httpd start

/etc/init.d/uptime4_core start



=================================================



For the first run, we created the first four snapshots; now the script manages these.

Subject: None

From: Joel Pereira <joel.pereira@uptimesoftware.com>
Date: 6-14-2007

Comment: The only other clarification that I recommend is when shutting down the up.time services to shut them down in the following order:

/etc/init.d/uptime4_core stop

/etc/init.d/uptime4_httpd stop

/etc/init.d/uptime4_datastore stop



The reasons for this are:

The up.time 4 Core depends on the Datastore (database), so the Core should be stopped first and then the Datastore so that there are no problems.

The httpd process (Apache web server) can be started and stopped at anytime as it is seperate from the other 2 processes.

Subject: None

From: Yasir Mughal
Date: 10-4-2007

Comment: How often do you back up. If this is a real NOC setup to monitor a 24/7 operations then won't monitoring be off the air for few minutes? while uptime is being restarted.


Copyright © 2021 IDERA, Inc.   Legal   Privacy Statement