Puredisk Hardware Migration

Hi Mark

As far as I'm aware your two options are to

1. Do a full DR backup on Server 1 and then a DR restore to the new server 3. You would need to stay at 6.5.1.2 and then upgrade after the DR restore.

2. Move all the clients from Server 1 to Server 3 , keep server 1 running for the retention time and turn it off when your data is out of that period ( we keep data on disk for 30 days but write it off to tape every 7 days so effectively we could turn our servers off after 7 days and then just restore from tape). This method you would have to re-do all your templates etc.

You can replicate data from Server 1 to Server 3 which will help populate the data. if the clients are LAN to the SPA it may not be worth doing but if they are over slower WAN links you could do this. I found doing this previously it can be quite slow.

 

Hope this Helps

Simon

Hi Simon,

1.  This is unfortunately not possible since we have no spare hardware or storage capacity.

2.  I think this will be my most likely strategy. We have daily retention of 30 days and monthly retention of 14 months with no write-off to tape. Luckily we're not a big environment (6TB data) so re-doing all the templates/etc won't take long.

In the Administrators Guide(p131) it states that 'You can use the replicated data selections to restore a Puredisk storage pool'. Do you know how this works? It suggests that I can use the replicated data on Server 2 to build Server 3. (Perhaps it just involves creating a replica policy from Server 2 to Server 3).

If I replicate from Server 1 to Server 3 then under Data Management on Server 3 I will have:

Client 1

- [R] Daily Data Selection (this is the data selection replicated from Server 1)

- Daily Data Selection (re-created data selection)

This will look a little messy if a client has many selections. Replication from Server 1 will eventually be stopped once the data has been copied and the clients are backing up to Server 3 - would this remove the [R] from the data selection and merge the two above? I suspect not.

With Option 2, do you recommend installing Server 3 as 6.5.1.2 or would it be ok to install it as 6.6.1? (Replica partners can be a higher PD version).

 

 

No worries - you've been more than helpful! (better than the answers I've had from Symantec)

Regarding sticking with 6.5.1.2, I did not word that correctly. I meant that during the migration process would it be safer to install 6.5.1.2 on Server 3 rather than 6.6.x (so that I'm doing the migration all at the same level) before migrating them all to 6.6.x later on.

Thanks for your answers and advice.

 

Either upgrade both servers to 6.6 or leave them at 6.5.1.2  and then upgrade Server 3 later. There is many issues around replication compatibility using different SPA versions.

 

Personally I'd upgrade both to 6.6 level as mentioned earlier, the replication features in 6.6 are faster then 6.5.1.2.

 

Simon

Ah ok, that makes sense.

One last quick question: do I need to worry about agent ids at all? As in, when I reinstall the agents on the clients to point to Server 3 should I just let Puredisk assign the ID?

Just leave it to PD to decide. Agent numbers are only important when you are re-installing the client to the old SPA. (server 1)

 

When you are pointing it to a new SPA (server 3)  it has no idea about that Client so just leave it blank.

Ok will do.

After "servername.com.au" is backing up fine to the server you can delete the [r] servername.com.au agent as it wont be required any more. Dont forget to run the Data Selection Removal Policy after deleting any agents etc.

I noticed a problem when testing this. If I delete the [r] servername.com.au agent then I can't access the data it backed up. When I do a restore from the servername.com.au agent I can only restore from the date it first backed up. To restore from an earlier date I have to use the [r] agent, which doesn't seem right.

Hi Mark

You can not transfer "history" as such. The only point of replicating in this example is to pre-seed the Finger print Database so when you cut over from Server 1 to Server 3 , the initial "FirstRun" backup wont take several days (well depends on the server size) as most of the data will allready be on the server.

 

You need to keep Server 1 online for the retention of the Data. As I mentioned, in my example we backup to disk for 30-45 days but write off to tape every 7 days so I would only need to keep my server online for 7 days and then could effectively restore from Tape.

 

The data in "[r] servername.com.au" and "servername.com.au" should effectively be the same data and thats why when your backing up to Server 3 with "servername.com.au" you dont need the [r] version any longer.

 

There is only two ways to keep historical data.

1. Keep the old server online until data is expired or

2. Do a full DR backup of Server 1, and then A Full DR Restore to Server 3, so effectively your new server is Server 3 but it looks like Server1 still to everything else in your environment.

 

The 6TB of Data, Will be restored if its Direct Attached else if its on SAN you could unpresent it from Server 1 and Present to Server 3 (or move the HBA's to the new machine). Also being Vxfs you can Mirror/Raid it to new Luns etc.

 

If in doubt log a support case to get you through it.

I hope this is a little clearer :)

Simon

Hi Simon,

Yes, that's much clearer.

Thanks again for everything, you've been great :)

Mark