I spoke with one of my colleagues on this. Even if we copied the backup into the client account for the accelerator at the DR site and if the client could be convinced to use that backup as the base for an incremental (which is a big "if"), the inode numbers on the source and target would have to be exactly the same for every file for the backup to succeed. I don't think VNX replication preserves inode numbers.
I think the best you'll be able to do is copy the p_cache.dat file from the source accelerator to the DR accelerator and run a level 0 of the DR target array. Most of the data will already be on the Avamar server so it will be a relatively fast L0 but it will still be an L0.
NDMP doesn't use the file cache so the benefit you'd get from the caches would be relatively small. Instead of using the file cache, Avamar NDMP relies on having a previous backup available to use as a base and asking the array for the list of files that have changed since that backup was created.
The NDMP client retrieves a list of recent backups from Avamar and records the dump date of the most recent matching backup. When the NDMP client sends the L1 backup request to the VNX, it uses this dump date to request only the files that have changed since the previous backup.
In 6.1 and older versions of Avamar, there is an issue with backing up arrays that are replication targets due to the way replication interacts with modification dates -- it's possible for replication to break a file's history chain in a way that causes backups to fail. This is resolved in 7.0 as long as there are no files on the array where the modification date is in the future.
we are running version 7, so it is possible that I can just setup a new ndmp node at our DR site, and just run a backup and it won't take that long? If I am reading what you wrote write, or hoping that would be the case in my mind
I will give that a shot and see what we get. As long as I can get backups a some point in time, if I were able to just copy some info over and just start off from the last backup that would have been great. But I guess sometimes you can't have your cake and eat it to!
Once you get over the L0, the cost of keeping backups of the DR target running is relatively low -- they won't consume additional capacity on the Avamar server. Probably best to just keep them running in case you find yourself in this situation again.
ionthegeek
2 Intern
•
2K Posts
0
June 26th, 2014 11:00
Unfortunately I don't think that will work.
I spoke with one of my colleagues on this. Even if we copied the backup into the client account for the accelerator at the DR site and if the client could be convinced to use that backup as the base for an incremental (which is a big "if"), the inode numbers on the source and target would have to be exactly the same for every file for the backup to succeed. I don't think VNX replication preserves inode numbers.
I think the best you'll be able to do is copy the p_cache.dat file from the source accelerator to the DR accelerator and run a level 0 of the DR target array. Most of the data will already be on the Avamar server so it will be a relatively fast L0 but it will still be an L0.
ionthegeek
2 Intern
•
2K Posts
0
June 26th, 2014 10:00
NDMP doesn't use the file cache so the benefit you'd get from the caches would be relatively small. Instead of using the file cache, Avamar NDMP relies on having a previous backup available to use as a base and asking the array for the list of files that have changed since that backup was created.
The NDMP client retrieves a list of recent backups from Avamar and records the dump date of the most recent matching backup. When the NDMP client sends the L1 backup request to the VNX, it uses this dump date to request only the files that have changed since the previous backup.
In 6.1 and older versions of Avamar, there is an issue with backing up arrays that are replication targets due to the way replication interacts with modification dates -- it's possible for replication to break a file's history chain in a way that causes backups to fail. This is resolved in 7.0 as long as there are no files on the array where the modification date is in the future.
Anonymous User
1 Rookie
•
55 Posts
0
June 26th, 2014 11:00
we are running version 7, so it is possible that I can just setup a new ndmp node at our DR site, and just run a backup and it won't take that long? If I am reading what you wrote write, or hoping that would be the case in my mind
Anonymous User
1 Rookie
•
55 Posts
0
June 26th, 2014 11:00
I will give that a shot and see what we get. As long as I can get backups a some point in time, if I were able to just copy some info over and just start off from the last backup that would have been great. But I guess sometimes you can't have your cake and eat it to!
thanks for your help.
ionthegeek
2 Intern
•
2K Posts
1
June 26th, 2014 12:00
Once you get over the L0, the cost of keeping backups of the DR target running is relatively low -- they won't consume additional capacity on the Avamar server. Probably best to just keep them running in case you find yourself in this situation again.
My pleasure!