Quantcast
Channel: Backup Software for Windows Servers | Backup Software for Virtual Machines
Viewing all 587 articles
Browse latest View live

Orphaned Recovery Point Appears after Resuming Replication and Before Consuming the Outstanding Seed Drive

$
0
0

Affected Builds

AppAssure 5.3.x

Description

An orphaned recovery point appears for the replicated agent on the slave core after replication is resumed on the Outgoing Replication on the master core (after a seed drive is created but it has not yet been consumed on the remote core). The “Outstanding Seed Drive” on the master core’s replication has not been abandoned either.

Resolution

This behavior is by design and should be expected.

On the slave core, for the replicated agent you should expect to see an orphaned recovery point for the very first recovery point in the chain. This is because replication had been allowed to resume so the very next recovery point after the seed was created) was picked up and replicated to the remote core, thereby it has been displaced from its recovery chain.

As soon as the seed drive has been consumed on the remote core, the orphaned recovery point will return to a normal recovery point since it will then be paired with its recovery chain when the data is copied over to the repository where the replicated agent resides.

If replication was still paused, then once the seed drive was consumed and replication resumed, then you should not expect to see any orphaned recovery point when the data has been allowed to fully replicate going forward until the next time you seed again.

Please refer to the following KB articles for more details:

 


How to Change NIC Binding Order

$
0
0

Affected Builds

Replay 4 Build 4.x

AppAssure 5 Build 5.x

Introduction

This article describes how to change the binding order of NICs on servers that have multiple network interfaces.

Description

AppAssure will run on the primary NIC in the binding order.  Changing the binding order will allow you to specify the network over which backups will be transferred.

Solution

 1. Click Start -> Run.  Type ncpa.cpl, and click OK

You will then see the available connections in the LAN and High-Speed Internet section of the Network Connections window.

2. On the Advanced menu, click Advanced Settings -> Adapters and Bindings

3. Under Connections, select the connection you want to use for AppAssure, and use the arrow buttons to move it to the top of the list

 

Replay 4 Replication Fails with No Errors

$
0
0

Affected Builds

Replay 4 Source and Target Core Build 4.x

Introduction

This article describes one scenario whereby Replay 4 replication may fail for one Agent with no error or warning messages.

Description

Replication starts failing for one Agent with no errors.  If you open the Replay.log file on the Target Core, you find this event:

DEBUG 11/19/13 08:06:30 [4076] – Open error on 185382af-98c9-11e1-8158-0050568920fb_13022.ReplayEPS – The system cannot find the file specified.
Src: AAFileHeader
Ctx: Agent03 Reading file header ‘185382af-98c9-11e1-8158-0050568920fb_13022.ReplayEPS’

Each Replay recovery point consists of two files: a data file (e.g., 185…b_13022.ReplayEPS) and an index file (e.g., 185…b_13022i.ReplayEPS).  The data and index files for a particular recovery point will have the same epoch number (in this case, 13022). Replicated recovery points also have a third file: A32, which is a checksum file. That file is only present in the staging area (repl folder), and once the checksum has completed, that file is deleted and the other two files are moved into the main repository folder for that agent (e.g., E:\tevorepository\Agent03).

For example, the Source Core sends all three files for a recovery point to the Target Core, and the Target Core receives them and acknowledges receipt.  Then something goes wrong when the Target Core is flushing that data from memory to the repository disk, so only one of the two recovery point files (with or without the A32 file) gets flushed.  The Source Core is still under the impression that that recovery point has already been successfully replicated, so it doesn’t need to be re-replicated; but the Target Core recognizes that the data isn’t actually present in the repository.  Since one of the files is present in the staging area, it assumes that the Source Core is in the process of sending the other one, so it doesn’t re-request that recovery point.  However, the Target Core is unable to mount any subsequent recovery points because it’s missing one of the points in the chain. As a result of all this, replication fails.

Solution

Open the “repl” folder within the repository for the problematic Agent on the Target Core.  If you find that there is only one recovery point file (either the data or index file) for a given recovery point, please perform one of the following two options:

  1. RECOMMENDED: Stop the Replay Core and ReplayXML Command services on the Target Core.  Delete the problematic recovery point file from the repl folder (and the associated A32 file, if present).  Start the Replay services on the Target Core.  The Target Core will re-request the recovery point that was causing problems, and replication will resume unhindered.
  2. If the recovery point file is the data file and if it’s particularly large, you could follow these steps instead.  We don’t recommend this since it won’t run the checksum against the recovery points, and therefore you could run into integrity issues.  Stop the Replay Core and ReplayXML Command services on the Target Core.  Manually copy the missing file from the Source Core repository to the Target Core repository.  Also move the file from the repl folder into the repository, and delete the associated A32 file, if present.  Then start Replay services.  Replication will resume unhindered.

Central Management Console asks for administrator rights when adding cores

$
0
0

Affected Builds

AppAssure 5 Central Management Console Build 5.3.1 and newer

Problem Description

When logged in to a machine with local administrator rights the Central Management Console (CMC) states that you need administrator rights to add a core server.

Resolution

To be able to view cores in the central console, the user account being used to log in must be a member of the domain admins group.

  1. In Active Directory please add the user account you wish to use with the CMC to the “Domain Admins” group
  2. Open Central Management Console as that user

A workaround without adding a user to domain admins group, perform the following:

  1. Open a Central Console with a local user from the administrator group
  2. In the CMC navigate to manage and then add a new group using the “add group” button
  3. Select the created group and click on the Access tab
  4. Click the Add button and grant access to a user from the domain by entering the account in the form <domain_name>\<user_name>
  5. Close the browser window and open the CMC with the domain user you just granted permissions to
  6. In the CMC navigate to Manage, select the group that was created and add Cores

Locally Cached epoch Not Found

$
0
0

Affected Builds

Replay 4 Core/Agent Product Build Number 4.7.2

Problem Description

The Replay core logs the following errors:

The storage location epoch chain key corrupt or/missing.

“AgentDisplayName” statement ‘SelectEpochsByLastChangedTime’ failed with ‘Locally cached epoch was not found; ‘AgentDisplayName’ epochKey ‘XXXX’.

Resolution

  1. Stop Replay 4 services
  2. Reboot Replay Core server
  3. Ensure Replay services start
  4. Perform a resync of the affected agent
  5. Force a new base image of affected agent
  6. Force a new incremental snapshot of the affected agent to verify snapshots complete successfully

 

Exchange DLLs repeatedly uploading to target core

$
0
0

Affected Builds

AppAssure 5.3.x

Problem Description

Core server reports multiple attempts to upload the Microsoft Exchange DLLs.  The upload may fail or succeed and the Exchange DLLs may exist on both the source and target cores.

Resolution

This issue may be caused by errors in accessing the Exchange dll files on the core server.

  1. On the target core browse to C:\Program Files\AppRecovery\Core\CoreService\MR\
  2. Delete the folder ‘E2010′
  3. Repeat steps 1 and 2 on the source core
  4. Force a snapshot of the Exchange agent which will also trigger a replication
This process will cause the Exchange DLLs to be downloaded new by the source core server and then uploaded to the target core.

Agent Export Configuration for Agent has been changed

$
0
0

Affected Builds

AppAssure 5.3.x

Problem Description

User receives the following Alert for Virtual Exports when no changes have been made by the user:

“Agent Export Configuration for Agent <Agent-Name> has been changed”

Resolution

 This alert is working as intended. The alert is generated whenever a new snapshot is exported to the .vhd location. This export is considered a configuration change.

You can elect to turn this alert off by following the steps below:

  1. Go to the Core -> Configuration tab -> Events
  2. Click on the “wrench” button to the right of the applicable notification group
  3. Navigate to All Events -> Export
  4. Uncheck “AgentExportConfigurationChanged”

Agent does not automatically start after boot

$
0
0

Affected Builds

AppAssure 5.3.x

Problem Description

In some instances (specifically Server 2003) the agent service may not start automatically after a reboot of the system.  In this case the agent starts properly when manually starting this.  There are also no other errors generated by the service in the system or application logs for the server.

Resolution

In this case, you may be able to resolve this problem by extending the timeout period for all services within the Registry.

Please, use the Registry Editor to change the default timeout value for all services.

  1. Make a backup of the registry before making any changes
  2. In the Registry Editor, select the registry subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
  3. In the details pane, right-click the ServicesPipeTimeout entry and select Modify. (Note: If the ServicesPipeTimeout entry does not exist, you must create it by selecting New on the Edit menu, followed by the DWORD Value then typing ServicesPipeTimeout, and clicking Enter.)
  4. Set the value to a decimal and enter the new timeout value in milliseconds.  The default should be 120000 milliseconds (2 minutes).  It may be necessary to increase this value to 300000 (5 minutes)
  5. Click OK to save the value
  6. Restart the computer for the change to take effect

Please note that this resolution will extend the timeout for all services to start on the server.  This may cause slower start up times for a server and is only recommended as a last resort.

 


How to use the AppAssure API to collect information about the core status

$
0
0

Affected Builds

AppAssure 5.3.x

Problem Description

In some cases the Core Web UI may become slow or unresponsive.  In this case you may be able to get some information about the core’s activities using the AppAssure API.

Resolution

To use the AppAssure API to collect information about the core status, we simply need to make REST calls to the Core Engine.  A REST call is an URI. In the case of the AppAssure API, REST calls are composed of a root (which is always the same) and a command string which is detailed in the AppAssure 5 API Documentation (http://docs.appassure.com/display/AA50D/AppAssure+5+API+Documentation). Please note that some of the calls are case sensitive.

The URI root is always “https://<Core-Name>:8006/apprecovery/api/core”, where <Core-Name> is the name of the Core (i.e. BAckup01) and the command is appended to that URI.

For instance, the command to query all events on the core is “/events/core/alerts/all”.  Hence the full URI call will be: “https://<Core-Name>:8006/apprecovery/api/core/events/core/alerts/all”.  Entering this string in a browser will yield an XML response containing all the alerts.

In a similar manner you can get a wealth of real time information such as the items in the transfer queue: “https://<Core-Name>:8006/apprecovery/api/core/xfer/queue/entries”

You can also gather a list of pending jobs:  ”https://<Core-Name>:8006/apprecovery/api/core/xfer/queue/pendingEntries”

Please refer to the documentation for more information regarding the capabilities of the AppAssure API.

Using Perfmon to asses disk storage performance for an AppAssure Core

$
0
0

Affected Builds

AppAssure 5.3.x

Problem Description

You may suspect that your AppAssure Core is experiencing slow performance due to your storage.  To verify the performance of the storage you can use a streamlined Perfmon data collector set to get a better understanding of how the storage is performing.

Resolution

  1. Open PerfMon and create a new user defined Data Collector Set.
  2. Choose the “Create Manually (Advanced)” radio button
  3. Choose “create Data Logs” and check all three options in the next screen
  4. Click next again and then select the following counters. (Please note that counters are grouped in objects; scroll to the object, expand it and select the counter; select the instances to asses [i.e. d: and E:] click “Add” to enable it).

- Object: Physical Disk, Counter: %Disk Time

If this value is consistently high and disk queue length is greater than 2, suspect the disk.

- Object: Physical Disk, Counter: Average Disk sec/Transfer

A high value (values greater than 0.3 seconds) may mean that the disk controller is continually retrying the disk because of failures.

- Object: Physical Disk, Counter: Current Disk Queue Length

Calculate Average Queue Time = Disk Queue Length x Average Disk sec/Transfer.  The number of disk commands waiting in the queue is normally the factor that slows disk performance by increasing the average disk queue time.

- Object: Physical Disk, Counter: Disk Bytes/sec

A Disk Bytes/sec count lower than 20K may indicate that an application is accessing a disk inefficiently.

After configuring PerfMon to use these counters, run the data collector set for a 24 hour period to gather a large data set.  Using this data you can then get a better idea of how the storage is performing.

How to use the AppAssure API to cancel active jobs on a core

$
0
0

Affected Builds

AppAssure 5.3.x

Problem Description

In some cases you may need to cancel an active job, however the Core Web UI is slow or unresponsive.  In this case you may attempt to use the AppAssure API to cancel the job.

Resolution

The best way of cancelling active core jobs when the Web UI is slow or unresponsive is through AppAssure API REST Calls.  You will need to have a REST Console available in order to make this form of API call. If you already use Chrome, please note that a free REST console is available on the Chrome Webstore. The following guide assumes that you are using the Chrome Rest console.

REST has 4 methods: Get, Post,Put and Delete. Since the goal is to cancel AppAssure Active Jobs, you will need to use the DELETE method.  Please note that the REST calls are composed out of a root which, in this case is always: “https://<Core-Name>:8006/apprecovery/api/core” where <Core-Name> is the name of the Core (i.e. Backup01) and a command which completes the call URI.  For instance, appending “/events/core/alerts/all” to the root so the URI is “https://<Core-Name>:8006/apprecovery/api/core/events/core/alerts/all”, yields all the alerts on the core.  Wherever applicable, AppAssure API calls are case sensitive.

To cancel a job you need to go through the following process:

  1. List all active Jobs on the Core in a tab of the browser (the example below assumes that you have max 10 active jobs on the core; running the URI below after cancelling each job will list any new jobs that may have been queued) “https://<Core-Name>:8006/apprecovery/api/core/jobmgr/jobs/core/paged?filter=Active&max=10&page=1.”   You will get an XML formatted reply containing a information about all active jobs
  2. Identify the Job you want to cancel first then Job ID of that job. It will be a unique ID like “7a52ee23-6fcf-4c42-a1a8-285c8ac83565″
  3. Switch to the REST Console in another Chrome Tab. In the Target Box enter the following string: “https://<Core-Name>:8006/apprecovery/api/core/jobmgr/jobs/<JobId>”.   For instance, assuming that the core name is backup01 and the job ID is the one in the example above, it will be “https://backup01:8006/apprecovery/api/core/jobmgr/jobs/7a52ee23-6fcf-4c42-a1a8-285c8ac83565
  4. Scroll down to the Methods (they are displayed as button on a bar at the bottom of the page) and click the “Delete” Button.
  5. The call should complete in a few seconds. Scroll down to the Response section and check the result.  For instance, 200 OK is the generic success status when there is nothing special to report, while 500 means Internal Server Error
  6. Go back to the tab you used to list the active jobs, refresh the page and select the next job id. Cancel it using the same process. Repeat the operation until all active jobs have been cancelled.

For more information about active jobs access using the AppAssure API, including how to cancel child jobs if needed, please refer to the following page: http://docs.appassure.com/display/AA50D/IBackgroundJobManagement

How to migrate an AppAssure Core to a new server

$
0
0

Affected Builds

AppAssure 5.3.4.x and newer

Problem Description

At some point it may become necessary to migrate your core server to new hardware or to a new server.  The following article details the steps necessary to complete this process.

Resolution

  1. Pause all protection and replication.
  2. If using replication, delete the replication from the target core and keep all recovery points.
    1. You will see the agents change to a status of “Recovery Points Only”
  1. If using encryption keys you will need to export each encryption key and copy it to the new core server.
  1. Make detailed notes of your current settings related to retention policy, transfer settings, replication settings, and any other settings that you have customized
  1. Stop the core service and disable it so that it no longer runs.
  1. If the repository is on direct attached storage, copy the entire contents of the repository and any extents to the new server.  If the repository is on network storage then verify the path to it.
  1. Install the same version of the AppAssure Core on the new server.
  1. Set the retention policy on the new core server to match that of the previous core server
  1. In the core -> Configuration Tab -> Repositories choose Actions -> open existing repository.  Point this to the location of the repository you copied to the new server.  This will mount the repository and load all the recovery points inside.
  2. If using encryption you will need to import the encryption keys into the core and then unlock it with the passphrase.
  3. Use the bulk protect tool to protect all agents that were protected by the previous core.
    1. Once protected, all recovery points in the repository will match back up with the protected agents.
    2. Make sure to set the protection intervals for the volumes on each agent to the same settings as previously used
    3. Protection will resume where it left off taking new incremental snapshots.  A base image should not be required as AppAssure has the previous agent data from the repository.
  1. If you were using replication on the previous core create a new pairing relationship between the new core and the target core.
    1. After successful pairing you will see the agents on the target core change from “Recovery Points Only” to “Replicated Machines”.
    2. Replication will resume and synchronize the target core with the source.
  1. If you were using Virtual Standby you will need to configure the virtual standby settings again for each agent and perform new exports.
    1. When configuring the connection with the Vmware or HyperV environment an entirely new virtual export will be necessary due to the fact that Vmware and HyperV will see the export as entirely new.
  1. If you were using SQL attachability checks you will need to install SQL on the new core server and configure the settings for attachability.
  1. If you were using Event notifications you will need to configure the SMTP settings and notifications

After completing all of these steps verify that all core operations run properly and no errors are generated.

Repository is Missing for an Agent

$
0
0

Affected Builds

AppAssure 5.x and newer

Problem Description

When an agent is added to the Core it shows: “Repository is Missing”

Resolution

To assign a repository to an agent:

  1. Click on the agent with the issue
  2. Click on the Configuration tab
  3. On the Settings tab
  4. Click Change
  5. Check to see if you are able to change the repository [You should not be able to change the repository if there is already one set and is not missing.]
  6. If you are able to, then select the desired Repository from the drop-down menu
  7. Click Save

Deleting an AppAssure Repository

$
0
0

Affected Builds

AppAssure Core Build 5.3.x

Description

This article details the steps necessary to delete an AppAssure 5 repository.

WARNING: This operation will delete all items contained within the repository folder. Dell does not recommend deleting a repository.

Solution

Complete the following steps.

WARNING: When a repository is deleted, the data contained within is discarded and cannot be recovered.

  1. On the Configuration tab, click Repositories, and then select the right angle bracket > symbol next to the repository you want to delete.
  2. In the Actions pane, click Delete.
  3. In the Delete Repository dialog box, click Delete.

How to cancel all active jobs on a core using Powershell v3.0

$
0
0

Affected Builds

AppAssure Core Build 5.3.x

Problem Description

It may be necessary at times to cancel all active jobs on a Core. Due to a long queue or the unavailability of the Web UI there is no direct path to achieve this goal. You can use the AppAssure API, but this only allows you to cancel one job at a time manually using REST calls from a Chrome REST Console and this process may take a long time.

Resolution

A Powershell Script was prepared to address the issue. In short, the REST Calls are performed directly from Powershell. The script continuously scans the active jobs in 5 seconds increments, shows the jobs which are active and attempts cancelling the running jobs one at a time. The process is repeated until no “running” and “cancelling” jobs are found. Since the interval between finishing cancelling a job and starting a new one from the queue may be longer than 5 seconds, the loop does not stop automatically when no new jobs are found (it can be stopped by hitting CTRL-C). The code performing the loop operation is provided and can be un-commented should you desire. The Powershell script code is provided below.  Please note that while AppAssure does provide powershell scripts for certain tasks the AppAssure support team does not officially support them.

#Cancel All Active Jobs On a Core
Write-Host “`r`n`r`nCancel Active Jobs`r`n——————–”
Write-Host “CTRL-C to Exit`r`n”
$corename = $env:computername
Write-Host “Local Computer Name: $($corename)`r`n”

$i=0
#Loop Indefinetly
for(;;){
#get active jobs via a REST call
$jobs = invoke-restmethod -URI “https://$($corename):8006/apprecovery/api/core/jobmgr/jobs/core/paged?filter=Active&max=10&page=1″ -Method “Get” -usedefaultcredentials

#Uncomment the line below if you want to script to stop when no active jobs are present. Not Recommended
#if(!($jobs)) {break;}

#Cycle through the discovered active jobs and show them on the screen
foreach ($job in $jobs.joblitelist.joblite){
Write-host “Job: $($job.summary), Status=$($job.status)”

#Cancel the running jobs
if ($job.status -eq “Running”)
{
#get and show Job ID
$id = $job.id
Write-host “Attempting to Cancel Job $($id)” -F “Yellow”

#Attempt Cancelling the Job; Some jobs may not be cancellable; draw user’s attention
Try{
$z = invoke-restmethod -URI “https://$($corename):8006/apprecovery/api/core/jobmgr/jobs/$id” -Method “Delete” -usedefaultcredentials
}
Catch{Write-Host “Error on job $($job.summary)`r`nIs it cancellable?” -F “Red”}
}
}

#Pause and iterate again through the jobs

start-sleep 5
$i++
“Loop#$($i) —————————————————–`r`n”
}


How to enable Deduplication and Compression on a Repository

$
0
0

Affected Builds

AppAssure 5.x

Description

It is possible to enable or disable deduplication and compression on a Repository.  This guide explains how to enable or disable deduplication or compression on a repository.  Please note that deduplication and compression are enabled by default on any new repository.

Resolution

  1. On the core console, select the core name in the top left.
  2. Select the Configuration tab on the right side.
  3. Expand the repository or repositories present on the core by clicking on the arrow next to the repository.
  4. Click on Settings.
  5. Confirm that the appropriate check boxes are checked for enabling deduplication and/or compression.

Fix Configuration Errors – Agent Volume is showing as Missing

$
0
0

Affected Builds

AppAssure 5.x

Problem Description

After a volume is deleted on an agent, the core reports that the volume shows as missing on the agent summary page.  You will also see a “Fix Configuration Errors” message on the summary page of the agent .  Until this is resolved, all snapshots will fail or be paused.

Resolution

To resolve this issue perform the following:

  1. Click on Fix Configuration Errors and it will bring up all the volumes
  2. Next to the volume that no longer exist there will be a link that shows “Delete”
  3. Choose Delete and the volume will be removed from the volumes screen
  4. Click Save.
  5. The core will refresh the volumes section and the volume will be gone from the volume list and the error will be gone
  6. The core will immediately begin taking a new snapshot of the protected drives

How to Protect a List of Agents when Manual Bulk Protection Fails Using PowerShell

$
0
0

Affected Builds

AppAssure 5.3.x

Description

There are situations when adding agents via the bulk protect in which the GUI fails. For instance, after moving the repository to a new core, attempting to bulk protect the agents on that core does not work, as it only protects the first agent in the list. All others will fail.

Warning: All scripts provided in this article are meant to be used as examples and are not supported by AppAssure. For more information on Dell | AppAssure scripting support, click here.

Resolution

A PowerShell script has been prepared to solve this issue. The script needs to be run on the core to protect the servers and has a series of limitations caused mainly by the AppAssure Powershell Commandlet. However, the script may prove to be very useful in the case of large deployments. Essentially, the script pauses all transfers (please note that this does not apply to the newly added agents which will be backed up as soon as a slot is available in the transfer queue), asks for the path of the file holding the agent names (need to be entered one per line) and provides a default path. Furthermore, a repository name needs to be entered. If no repository name is provided, the script will detect the repositories belonging to the deployment core and ask the user to choose the desired one for each server to be added to protection. In order to protect privacy, the credentials necessary adding servers to protection are processed via a popup window. This feature was implemented at the request of customer working with support engineers to avoid sharing the passwords in clear text. Once the credentials are entered the script contacts each agent via a WMI call and collects the list of available logical disks. Please note that the System Reserved Partitions are not detected and need to be added manually, which is the first limitation of the script. The second and more important limitation is that there is no way to pause initial transfers or set a protection schedule at the time of adding the server to protection.

 

Write-host “`r`n`r`nAdd Agents To Protection” -F “Green”
Write-Host “————————”
Write-Host “CTRL-C to EXIT`r`n”

Write-host “Pausing all snapshots`please do not forget to re-enable them when all the operations are finished” -f “Yellow”
suspend-snapshot -all

#default path of the file with the servers’ names. Change with your preferred one.
$defaultFile = “c:\temp\agents.txt”

#get an alternate path interractively
Do {
$Agents = Read-Host “`r`nPath to the server list; default [$($defaultFile)]”
if($Agents -eq “”){$Agents=$defaultFile}
}
while (!(Test-Path $Agents -PathType Leaf))
$protectedagents = get-content $Agents

$repo = Read-Host “`r`nEnter Repository Name no double quotes if multiple words, please`r`nIf not sure, hit Enter and you will be

asked for each agent`r`n”

Write-Host “We assume that all agents on the list can be added to protection using the same`r`nusername and password`r`n”
$crd = Get-credential
$username=$crd.username
$password=$crd.getnetworkcredential().password

foreach ($agent in $protectedagents)
{
$agent
Write-host “Attempting Protection” -F “Yellow”

$drives = get-wmiobject Win32_logicaldisk -computername $agent -credential $cred | where {$_.drivetype -eq 3} | select-object -

expandproperty deviceid
start-protect -repository $repo -agentname $agent -agentpassword $password -agentusername $username -volumes $drives
start-sleep 2
}

Replay Reports Display Ex-Agents

$
0
0

Affected Builds

Replay 4.x

Description

After removing agents from protection, the Replay reports still list those ex-agents with zeros for all jobs

Solution

If you are using the default reporting database:

  • On your core, stop the Replay Core and Replay XML Command services
  • Navigate to “C:\Program Files (x86)\AppAssure Software\Replay Server\Server64″
      o For 32-bit cores: “C:\Program Files\AppAssure Software\Replay Server”
  • Go to “Folder and Search Options”->”View”, and deselect the box marked “Hide extensions for known file types”
  • Rename the “Reporting.Database.sdf” file to “Reporting.Database.old”
  • Start the Replay Core and Replay XML Command services. The Reporting Database will recreate itself, this time without the ex-agents

If you have configured a centralized reporting database:

  • Replay Core and Replay XML Command services
  • Open the registry to HKEY_LOCAL_MACHINE\SOFTWARE\AppAssure\ReplayReport
  • Export a copy of the ReplayReport key to a memorable location
  • Change the value for “report_db_aliase” to C:\Program Files (x86)\AppAssure Software\Replay Server\Server64\Reporting.Database.sdf
    • o For 32-bit cores change the value to “C:\Program Files\AppAssure Software\Replay Server”
  • Change the value for “report_db_type” from 2 to 1
  • Remove the values for “report_db_user_name” and “report_db_user_password”
  • Start Replay services
    • o NOTE: If you are planning to upgrade your core to a later version of Replay, do so at this time
  • Stop Replay services again
  • Open your exported copy of the original ReplayReport key to import it into the registry
  • Start Replay services

Moving a volume from one server to another using AppAssure

$
0
0

Affected Builds

AppAssure 5.x

Description

This guide details the best practices for utilizing AppAssure to migrate a data volume from one server to another.

Some methods of moving a volume from one server (cloning, moving a LUN, etc.) to another server can result in AppAssure seeing duplicated volume metadata.  This duplicate metadata can result in issues accessing recovery points as well as having maintenance jobs like rollup run. For instance this may cause the error “Sequence contains more than one element” when mounting a recovery point containing the volume that was cloned.

Resolution

  1. Add or format a disk on the target server; in virtualized environments, create and attach a new virtual disk to the target server.
  2. Create the target partition. Be sure to make the target partition the same size or larger than the volume to be moved.
  3. If the target server is not yet under AppAssure protection, install the AppAssure agent software and add it to protection. (note that the agent installation requires a reboot)
  4. Select a recovery point containing the volume to be moved, click the angle bracket to expand the recovery point details, and click the Rollback option.
  5. Choose an alternate machine in the rollback menu, and follow the instructions for a live rollback in this KB: http://www.appassure.com/support/KB/how-to-perform-a-rollback-live-recovery-of-a-data-volume/
  6. Once this process has been completed all data from that recovery point will have been migrated to the new volume.  The agent will take snapshots of the new volume and there will be no issues with duplicate metadata.
Viewing all 587 articles
Browse latest View live