I thought the question was about the diffrence between avamar and networker? not between avamar and datadomain?
Avamar originally was a physical appliance that both was meant for the storing of the backlup data as well as providing the backup server software. It uses client side deduplication, so indeed deduplicating the backup data to be send by asking the avamar appliance what block were already there? Hence only a reduced amount of data would be send over the network once there was already data ingested.
It would be similar to compare to the combination of using Networker with a data domain as backup target. Leveraging the ddboost functionality from data domain integrated into the Networker client, similar to avamar, NW clients can perform "client direct", that is communicating directly with the data domain using its ddboost protocol, asking if it already knows the blocks of variable block length already. If so, then a block doesn't need to be send and only a pointer to the already existing block is needed on data domain end.
A big difference however is that the avamar client keeps a table of (recent) data blocks so that it can lookup itself if soem data blocks already have been send to the avamar appliance. Because of that additional storage space is required on the client to keep track of the blocks already on avamar end. NW/ddboost towards a data domain does not do that. It will need to ask for each and every block if the DD already has that. So by design the ddboost protocol is more chatty than avamar.
Avamar also had a rest api way earlier than NW had, so environments that heavily invested into automation based on rest api's, chose avamar over nw at the time (what I saw happening in our own company), also integrating it with for example vmware vRealize. The rest api functionality on avamar required a separate vm appliance (B&R), which was later also introduced for NW. However for NW the rest api was fully integrated into it from nw9 onwards (dunno what current status for that for avamar is).
As we deemed the avamar backup server at the time as not supporting enough os'es and especially not enough database/applications, we have used avamar still as backup target in a few NW server environments, which however was not a good marriage, as there were things like replication not being controlled by NW, daily avamar black-out window in which it performed its own housekeeping where it didn't accept any data ingestion, if avamar needed to be roled-back to an earlier snapshot due to issue, then NW wasn't able to scan in any data ingested after that issue, so which caused actuall dataloss (caused by a wrong NTP setting causing various avamar nodes to go out of time sync with each other), needing EMC support to perform avamar upgrades.
As we were already using datadomain, for us it was a no-brainer to use DD in favor of avamar as a backup target for NW. Haven't looked back since. YMMV however...
What you however see nowadays is that vamar also can have a DD backup target as backend, instead of its own storage solution. If I recall correctly, still it will store meta data on its own storage, while backup data is stored on DD, but even that might be different nowadays. I don't closely follow the avamar enhancements.
However if you ask the question about avamr/networker, then let's add PPDM (power protect data manager) to the mix, as that is the latest backup software from Dell (not counting the Druva co-operation) which offers similar functionality to avamar and networker, also able to use DD as backup target. The newest features like making snapshots of public clouds, backup of kubernetes, transparent snapshots of vmware vm's (not needing a proxy appliance on each cluster).
So we have out eyes open for PPDM besides NW, even though we don't consider PPDM mature enough yet to use in production, which also has to do with the range of clients and applications/databases that are supported, which is less than what NW offers.
Although their final goal is to minimize the amount of storage space for the backups, they follow total different concepts how to achieve that. Let me try to break this down as simple and as short as possible...
Avamar uses a storage system (a kind of 'backup device') to which only the changed data from the client will be transferred. So the amount of data (after an initial full backup) is usually (very) small which makes it ideal if you have a limited network bandwidth. However, to support it, you must also install a piece if Avamar software on the client because the compression is done there already.
A Data Domain is 'only' a dedupe storage system. This means that you must transfer all data to the system first where it is de-duped while it is stored. Consequently you need full network bandwith. But you do not need any software on the client.
It has been a while since my last contact with Avamar. It worked reliably as I remember. But IMHO it had a major disadvantage with respect to the reporting: Because the backup data is already compressed at the client, their size does not represent the 'true' amount of the source data.
The other caveat is that you cannot easily clone the Avamar save sets, especially not to tape.
barry_beckers
393 Posts
0
October 10th, 2022 00:00
I thought the question was about the diffrence between avamar and networker? not between avamar and datadomain?
Avamar originally was a physical appliance that both was meant for the storing of the backlup data as well as providing the backup server software. It uses client side deduplication, so indeed deduplicating the backup data to be send by asking the avamar appliance what block were already there? Hence only a reduced amount of data would be send over the network once there was already data ingested.
It would be similar to compare to the combination of using Networker with a data domain as backup target. Leveraging the ddboost functionality from data domain integrated into the Networker client, similar to avamar, NW clients can perform "client direct", that is communicating directly with the data domain using its ddboost protocol, asking if it already knows the blocks of variable block length already. If so, then a block doesn't need to be send and only a pointer to the already existing block is needed on data domain end.
A big difference however is that the avamar client keeps a table of (recent) data blocks so that it can lookup itself if soem data blocks already have been send to the avamar appliance. Because of that additional storage space is required on the client to keep track of the blocks already on avamar end. NW/ddboost towards a data domain does not do that. It will need to ask for each and every block if the DD already has that. So by design the ddboost protocol is more chatty than avamar.
Avamar also had a rest api way earlier than NW had, so environments that heavily invested into automation based on rest api's, chose avamar over nw at the time (what I saw happening in our own company), also integrating it with for example vmware vRealize. The rest api functionality on avamar required a separate vm appliance (B&R), which was later also introduced for NW. However for NW the rest api was fully integrated into it from nw9 onwards (dunno what current status for that for avamar is).
As we deemed the avamar backup server at the time as not supporting enough os'es and especially not enough database/applications, we have used avamar still as backup target in a few NW server environments, which however was not a good marriage, as there were things like replication not being controlled by NW, daily avamar black-out window in which it performed its own housekeeping where it didn't accept any data ingestion, if avamar needed to be roled-back to an earlier snapshot due to issue, then NW wasn't able to scan in any data ingested after that issue, so which caused actuall dataloss (caused by a wrong NTP setting causing various avamar nodes to go out of time sync with each other), needing EMC support to perform avamar upgrades.
As we were already using datadomain, for us it was a no-brainer to use DD in favor of avamar as a backup target for NW. Haven't looked back since. YMMV however...
What you however see nowadays is that vamar also can have a DD backup target as backend, instead of its own storage solution. If I recall correctly, still it will store meta data on its own storage, while backup data is stored on DD, but even that might be different nowadays. I don't closely follow the avamar enhancements.
However if you ask the question about avamr/networker, then let's add PPDM (power protect data manager) to the mix, as that is the latest backup software from Dell (not counting the Druva co-operation) which offers similar functionality to avamar and networker, also able to use DD as backup target. The newest features like making snapshots of public clouds, backup of kubernetes, transparent snapshots of vmware vm's (not needing a proxy appliance on each cluster).
So we have out eyes open for PPDM besides NW, even though we don't consider PPDM mature enough yet to use in production, which also has to do with the range of clients and applications/databases that are supported, which is less than what NW offers.
bingo.1
2.4K Posts
0
October 6th, 2022 00:00
These are total different concepts.
Although their final goal is to minimize the amount of storage space for the backups, they follow total different concepts how to achieve that. Let me try to break this down as simple and as short as possible...
Avamar uses a storage system (a kind of 'backup device') to which only the changed data from the client will be transferred. So the amount of data (after an initial full backup) is usually (very) small which makes it ideal if you have a limited network bandwidth. However, to support it, you must also install a piece if Avamar software on the client because the compression is done there already.
A Data Domain is 'only' a dedupe storage system. This means that you must transfer all data to the system first where it is de-duped while it is stored. Consequently you need full network bandwith. But you do not need any software on the client.
It has been a while since my last contact with Avamar. It worked reliably as I remember. But IMHO it had a major disadvantage with respect to the reporting: Because the backup data is already compressed at the client, their size does not represent the 'true' amount of the source data.
The other caveat is that you cannot easily clone the Avamar save sets, especially not to tape.
Therefore a DD is much easier to handle.
srini.bandi
1 Rookie
1 Rookie
•
1 Message
0
April 21st, 2024 13:11
@barry_beckers Thank you for clarification.
It's very useful..! :)
Regards
Srinivasa Rao Bandi