I can tell you my servers on the LAN take 2 hours to backup 225 GB.
I think the time it takes each server to process a backup is more dependent on how long it takes the Avamar process to scan through all the files, rather than how long it takes to send data between the client and the Avamar server.
Ensure cache files are tuned correctly as per the best practice guide attached.
For 1 million files 1 MB of file cache(f_cache.dat) is required and for 1 GB of database 1 MB of hash cache (p_cache.dat) is required. Generally we double the size coming out from above calculation and specify it asfilecachemax= andhashcachemax= in avtar.cmd
Also add below parameters to avtar.cmd created in C:\Program Files\avs\var
--stats
--status=300
Re-run backup and attach the log and we should be able to tell you if the speed is optimal from stats output.
I'm still testing Avamar, to see how good it performs when backing up to WAN. So, I didn't configured a proper dataset, using the default one, which backs up all partitions...
It happens that 2 partitions are used for backup via robocopy... And found the solution at BestPratices doc above which I explain:
The files may be equal on 3 partitions, but timestamps aren't (because all those files are created everyday) so Avamar client cannot find them at f_cache (checksum of file attributes) and processes them as new files (reading, chuncking, computing hashes...) which takes a lot of time. Later, client checks hashes against p_cache and discovers that the major of chunks is allready backed up and don't send them which makes Avamar Server believe that "New bytes" is around 1% (this value is based on the bytes sent to Avamar Server, not bytes processed by Avamar Client)...
So, to make things clear, the change rate isn't quite "extremelly low"... It's more like aroud 66% of all data (original + 2 backup partitions)...
Solution is simple: Backup only data partitions (not backup partitions)... In other server (not the one I was complaining) backup time dropped from 45 to 4 minutes.
In my case, it was a case of a replication process running at the same time. When the backup and replication do not coincide, the server backup only takes about 30 minutes:
2011-02-05 23:54:51 avtar Info <6083>: Backed-up 221.9 GB in 31.59 minutes: 421 GB/hour (369,681 files/hour)
JohnCrouch_a316b2
1 Rookie
•
28 Posts
0
February 3rd, 2011 11:00
I can tell you my servers on the LAN take 2 hours to backup 225 GB.
I think the time it takes each server to process a backup is more dependent on how long it takes the Avamar process to scan through all the files, rather than how long it takes to send data between the client and the Avamar server.
Sameer_Khan
121 Posts
2
February 3rd, 2011 15:00
Ensure cache files are tuned correctly as per the best practice guide attached.
For 1 million files 1 MB of file cache(f_cache.dat) is required and for 1 GB of database 1 MB of hash cache (p_cache.dat) is required. Generally we double the size coming out from above calculation and specify it asfilecachemax= andhashcachemax= in avtar.cmd
Also add below parameters to avtar.cmd created in C:\Program Files\avs\var
--stats
--status=300
Re-run backup and attach the log and we should be able to tell you if the speed is optimal from stats output.
Thanks and Regards,
Sameer Khan
1 Attachment
BestPractice5.0.pdf
rpervan
266 Posts
0
February 4th, 2011 00:00
What exactly you are backing up ?
file system, some kind of Data Base, .... what exact?
regards,
Rej
afarinha1
1 Rookie
•
20 Posts
0
February 4th, 2011 01:00
I'll try this.
I'll publish results by the end of the day.
Thanks a lot
afarinha1
1 Rookie
•
20 Posts
0
February 4th, 2011 01:00
In yout case it really takes a lot...
Your case can be also related with the changes occourred between backups. 2 hours with a LAN connection sounds a lot...
afarinha1
1 Rookie
•
20 Posts
0
February 4th, 2011 03:00
I may have found the trick...
I'm still testing Avamar, to see how good it performs when backing up to WAN. So, I didn't configured a proper dataset, using the default one, which backs up all partitions...
It happens that 2 partitions are used for backup via robocopy... And found the solution at BestPratices doc above which I explain:
The files may be equal on 3 partitions, but timestamps aren't (because all those files are created everyday) so Avamar client cannot find them at f_cache (checksum of file attributes) and processes them as new files (reading, chuncking, computing hashes...) which takes a lot of time. Later, client checks hashes against p_cache and discovers that the major of chunks is allready backed up and don't send them which makes Avamar Server believe that "New bytes" is around 1% (this value is based on the bytes sent to Avamar Server, not bytes processed by Avamar Client)...
So, to make things clear, the change rate isn't quite "extremelly low"... It's more like aroud 66% of all data (original + 2 backup partitions)...
Solution is simple: Backup only data partitions (not backup partitions)... In other server (not the one I was complaining) backup time dropped from 45 to 4 minutes.
JohnCrouch_a316b2
1 Rookie
•
28 Posts
0
February 7th, 2011 10:00
Thanks Sameer Khan.
In my case, it was a case of a replication process running at the same time. When the backup and replication do not coincide, the server backup only takes about 30 minutes:
2011-02-05 23:54:51 avtar Info <6083>: Backed-up 221.9 GB in 31.59 minutes: 421 GB/hour (369,681 files/hour)