Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

3801

February 23rd, 2017 06:00

migration from avamar-datadomain to avamar-datadomain

Hello,

We are currently using an avamar grid (10 nodes - 7.2) + DD   and we will replace it soon by another avamar grid  (3 nodes - 7.4 ?) + new DD

1) can we migrate specific backups currently located on the avamar grid (backups not on the DD)  to the new avamar grid  using the standard avamar replication process ?

2) we are doing some Remote Office backups to our current avamar grid (agent installed on the remote office client and backups done through the WAN to our avamar grid) - backups are now running well (good dedup) .

Is there a way to avoid Remote Office  full backups when we will attach these remote office avamar clients to the new avamar grid .

In other words when existing remote clients will be registered to the new avamar grid, will  the p-files and hash files be invalidated - forcing a full backups on the new avamar grid ? any solution to avoid full backups when switching to a new avamar server ?

February 24th, 2017 00:00

1) Client Manager can be used to migrate clients to the new Ava/DD system.  The task will essentially replicate the client backups and register and activate the client to the new system.  For more information look refer to the Avamar Administrator Guide and search for "Moving a client to a new server"

Another option for migrating clients and their backups is ADME.

2) The local client cache files will still be useful after moving the client to a different Avamar server because they still represent the data being backed up from the client.  On backing up to the new server avtar will use the hashes to check if the data they represent 'ispresent' on the new Avamar system.  Any unique chunks of data which aren't present on the server will be sent over the network.  This is where 'seeding' can come in useful.

The following article contains an overview of the concept of locally 'seeding' an Avamar server with client data

KB  442281 - Best practices when backing up remote clients via a WAN

215 Posts

February 24th, 2017 05:00

Be careful using client manager in this case. I assume the new 3 node Avamar GRID with DD is intended to be used for metadata only and if so then you cannot/should not migrate any clients whose backups are currently stored in the GSAN as this will result in establishing data stripes on the new GRID which can never be reclaimed and reused for metadata stripes.

For clients that currently have their backups in the DD today these can be migrated using client manager as suggested as these by default will be stored in the new target DD.

Therefore GSAN based clients in the source Avamar need to use a different approach for which ADMe can be used to migrate backups from a source GRID to a target Avamar and store them in its DD as a a net new backup while retaining all original file time stamps. ADMe provides required organization around segregation of each clients original backup date so the user can easily differentiate between these in the future if a recovery is needed from them.

Regarding seeding the target DD with remote clients data, ADMe can be used for this purpose by migrating the last available backup from each client involved to the target Avamar DD. This approach would only be needed for clients whose backups are in the source GSAN as any DD based clients can be replicated as described above.

4 Posts

February 26th, 2017 23:00

Thanks a lot

No Events found!

Top