Manage source data

As soon as a connection (either a normal or a guest one) to a replication destination machine has been established (through the Home > Replication > Replication source > Connection to a destination screen), it becomes visible and usable from this Manage source data screen.

You can open a connection simply by clicking the connection name. Thus, all data which can be managed through the opened connection will be displayed in the form of bar graphs. This includes:

What is showed by opening a connection is really a mixed view displaying both local and remote data.

Depending on whether you are using a normal or a guest connection, some kind of data is displayed and some actions become available:

Throughout the rest of this document, we will illustrate the capabilities available in the Manage source data screen by using simple examples.

Normal connections

First, we will look at normal connections. As a reminder, the main characteristic of a normal connection is that both replication and recover operations can be performed through such a connection: it is a kind of read-write connection.

Let's suppose that we have established a normal connection named myconnection to a remote replication destination machine. For information about how to open such a connection, please refer to the online help available in the Home > Replication > Replication source > Connection to a destination screen.

Let's suppose too that the source machine we are logged into contains one sole VTL named myVTL containing two backup data sets: one corresponding to the backup of a savepack named bin and another corresponding to the backup of a savepack named etc.

Data view

Now, we open the myconnection connection visible in the Manage source data screen. Here is what is displayed:

Following important information can be read from the view above:

Following actions can be performed:

Now, we want to replicate some data to the remote replication destination machine.

Data replication

Let's start an immediate replication of the backup data set from the bin savepack. To do that, we just have to click the icon next to the backup of bin savepack. As a result, a new window is opened making it possible to start the actual replication job. Thus, we just click the Start replication button to launch the job.

When the replication job has finished, we just close the popup window and refresh the view by clicking the icon. Here is the refreshed view as it is now displayed:

The image above introduces some new stuff:

The next step is to demonstrate data recovery.

Data recovery

We could just click one of the icons to open up the recovery window and start a recovery job. However, this would be a useless operation. Indeed, since remote data is already stored locally, doing this would actually result in the transfer of no data at all. There is generally no use in recoverying data which is already available locally (an exception to that is a case of local data corruption).

A usual case where we want to recover data is when we need to retrieve data that has been replicated, but is not available locally anymore. Several reasons could explain why data is not available locally anymore:

To demonstrate data recovery, we first perform a manual recycling of the backup of the bin savepack stored in the myVTL VTL. This can be done through the Home > Where to backup > Backup to disk > VTLs screen (just use the Backup list action menu).

After the data has been recycled, we come back to the Manage source data screen. Here is the new bar graphs view:

As expected, the backup of the bin savepack is not available locally anymore but is obviously still present remotely.

Let's start an immediate recovery of the backup data set from the bin savepack. To do that, we just have to click the icon next to the backup of bin savepack. As a result, a new window is opened making it possible to start the actual recovery job. Thus, we just click the Start recovery button to launch the job.

When the recovery job has finished, we just close the popup window and refresh the view by clicking the icon. Here is the refreshed view as it is now displayed:

Here are some comments about this new view:

To make recovered data really usable, it must be indexed. This is demonstrated in the next part.

Data reindex

A backup data set cannot be reindexed directly. A reindex operation is always performed against a whole VTL.

To reindex the backup data set recovered above, we have to reindex the myVTL VTL. To do that, we just have to click the icon next to VTL name. As a result, a new window is opened making it possible to start the actual reindex job. Thus, we just click the Start reindex button to launch the job.

When the reindex job has finished, we just close the popup window and refresh the view by clicking the icon. Here is the refreshed view as it is now displayed:

Recovered data is now really part of the myVTL VTL and is restorable. Actually, the view is exactly the same as before we recycled the data in the previous part.

Recoverying an entire VTL

Till now, we have seen how to:

However, how do we recover an entire VTL which has been replicated but does not exist locally anymore ? The idea is not only to recover remote data to an already existing local VTL, but to fully rebuild a VTL from replicated data.

To demonstrate a full VTL rebuild through a normal connection, we first replicate the full myVTL VTL. To do that, just click the replication icon next to the VTL name and start the replication. All backups stored within the VTL will be replicated.

Next, we delete the myVTL VTL. This can be done through the Home > Where to backup > Backup to disk > VTLs screen.

Here is the new bar graphs view when we come back to the Manage source data screen:

The myVTL VTL does not exist locally anymore but is replicated remotely, which is represented by the red lines. Obviously, no replication is possible, since there is no local data to replicate. Furthermore, no recover operation is possible either. Why ? Simply because a recover operation needs a target VTL to which data must be recovered, but there is no local target VTL yet.

To recover our VTL, we must first recreate it locally. This can be done by clicking the icon. This opens up a new window which makes it possible to recreate the VTL. Following information for the new VTL must be provided:

For our example, we choose to create a VTL named myNewVTL with a 512 MB capacity. Here is the new bar graphs view after we have created the VTL:

As you have guessed, we can now perform a data recovery of the full VTL through the icon.

Here is the new view, after the end of the recovery job:

The final step is to reindex the VTL through the icon. After the reindex job has finished, we have:

The VTL is now fully recovered.

Guest connections

In the previous part, we have discussed replication capabilities exposed by normal connections. As we have seen, a normal connection provides the ability to replicate the VTLs owned by the replication source machine. These replicated data could be recovered through the same normal connection.

However, it is not possible through a normal connection to retrieve data stored on the replication destination machine which has been replicated from a source machine different from the one we are logged into. This capability is provided by guest connections only.

For detailed information about guest connections and how to create them, please refer to the online help available in the Home > Replication > Replication source > Connection to a destination screen.

Basically, a guest connection provides a read-only access to data stored on the replication destination machine, which was not replicated from the current source machine. Actually, a guest connection makes it possible to move data from a replication source machine to another source machine through a common destination machine.

Managing a guest connection through the Manage source data screen is very close to managing a normal connection. Most of what has been discussed in the previous part about normal connections is applicable for guest connections too. However, there are some essential differences: