Would like to know what is the size of each tape..
If possible keep the size of the tape to be 100 GB, this makes the replication of the tape faster, than a 200 GB or a 300 GB tape.
Also, if possible split this large tape pool into two or three smaller pools and let them sync one by one, with each having 100 GB tapes. This should help.
Less tapes in a pool rather than smaller tapes would make a larger improvement, the guideline is under 1000 tapes in a pool, although more is supported. You seem to fit this fine.
Splitting the pool is possible without having TSM do the move of tapes via the backup server (this would negate needless reads and writes back to your DD via the backup application.
See EMC article;
Breaking Up VTL Pools For More Efficient Replication
If you're using pool replication, does that mean you are also pre 5.x code on your DD, hopefully beyond 4.7 at least?
Assuming that your replication ethernet link is not saturated, then splitting your pool up (2 would be fine I guess) and possibly upgrading your DDOS to latest GA may bring you some benefits.
Might be worth checking some basics, like cleaning is at a maximum of once per week.
I don't think you will see many articles that refer to the size of tape that you should use, personally I mostly agree with the other poster.
1TB is too large, 4TB is way too large. It would just mean that the tape is mounted for a long period of time until it is full, if your backup application idle timers are high then the tape may never eject for days.
100TB is possibly too small these days, maybe 200TB tapes are ideal but it depends on many factors, such as DDR model, storage available etc…
I would consider an upgrade to 5.4 if it was my DDR.
It’s the tape size you set that is important, the drive emulation (and it’s ‘real world/physical’ tape drive counterparts capacity and throughput specs) is pretty much academic other than for tape device drivers, I would use the newest drive emulation you can, so get the latest device drivers and set the tape size accordingly to your needs.
5.2.3.1 was generally a good code for VTL.
5.2.5.0 is latest 5.2 GA code.
5.4.2.1 is latest 5.4 GA code.
I would say, same size tapes in your system is just to keep it simple or your math can be complicated when calculating space used etc...
No excessive free slots or tapes just means that you are forced to re-use existing tapes rather than use new ones, again forcing space to be overwritten more frequently and existing tapes to be used/re-used rather than just sit there while a new tape is chosen.
Which I guess leads onto your final statement about using expired tapes before scratch tapes.
You can police this in the backup application but it’s simpler to keep your tape count down to a sensible amount for what you expect to need.
If you are going to reduce the tape size, which I personally would, then your tape count will go up to satisfy workload, in which case you will be into multiple tape pools to aim to keep under that “advised” 1000 tapes per pool, though your newer DDOS code is possibly better at handling this anyway.
Which type of replication method are you using (assume the latter?);
What is the difference between the VTL directory and Mtree type pool?
The VTL directory pool uses a directory in /backup/vtc to store tapes. (5.1 and before)
The VTL MTree pool uses an MTree for each pool in /data/col1/pool1 to store tapes (post 5.2).
If you upgraded to 5.2 (not new install at 5.2) then you would have had to have chosen to upgrade to VTL/Mtree replication.
Without it, that would mean you have a backwards compatibility pool and you will still be using directory replication, which just isn’t as ‘slick’ as Mtree replication because Mtree uses snapshots for replication.
If you have low backup retention specified then maybe you could create a new pool(s) to use with smaller tapes for new backups and then delete the old larger tapes as they expire.
I would try to avoid migrating data via TSM, it will just add workload on both sides – it will dedupe well but it still needs to be “handled”, rehydrated, re-deduped etc...
I hope that helps but it’s a fairly large topic with many aspects that need to be looked at and understood.
I would not expect any performance difference, but it will make sure that replication of a tape starts sooner as it is done upon close of the tape, which will be more frequent when using smaller tape sizes.
I read a while back that smaller a tape better the replication as one tape is considered as a file for replication, large tapes take time to replicate and can effect both RPO and RTO...
However it also depends on how replication is configured and ammount of bandwidth allocated..
We had 100 GB taoes in our environment and replication went fine for almost two years, even when we increased the capacity and amount of data written into the VTL both at source and destination data domains.
ShubhamMishra
40 Posts
0
June 8th, 2014 10:00
Hi Ignes
Would like to know what is the size of each tape..
If possible keep the size of the tape to be 100 GB, this makes the replication of the tape faster, than a 200 GB or a 300 GB tape.
Also, if possible split this large tape pool into two or three smaller pools and let them sync one by one, with each having 100 GB tapes. This should help.
Thanks, keep me posted of the results....
ignesingram
1 Rookie
•
59 Posts
0
June 9th, 2014 01:00
Hi.
Currently the setup at this customer is that they are using 1TB & 4TB tapes.
VTL Tape Summary
----------------
Total number of tapes: 755
Total pools: 1
Total size of tapes: 2105000 GiB
Total space used by tapes: 1431954.2 GiB
Average Compression: 31.2x
What would the ideal size of a tape be?
Is there a maximum number of tapes allowed in a pool and overall?
Cheers.
jbrooksuk
208 Posts
0
June 9th, 2014 02:00
Less tapes in a pool rather than smaller tapes would make a larger improvement, the guideline is under 1000 tapes in a pool, although more is supported. You seem to fit this fine.
Splitting the pool is possible without having TSM do the move of tapes via the backup server (this would negate needless reads and writes back to your DD via the backup application.
See EMC article;
Breaking Up VTL Pools For More Efficient Replication
If you're using pool replication, does that mean you are also pre 5.x code on your DD, hopefully beyond 4.7 at least?
Assuming that your replication ethernet link is not saturated, then splitting your pool up (2 would be fine I guess) and possibly upgrading your DDOS to latest GA may bring you some benefits.
Might be worth checking some basics, like cleaning is at a maximum of once per week.
Regards,
Jonathan
ignesingram
1 Rookie
•
59 Posts
0
June 9th, 2014 02:00
I am unable to access that article - get a Access denied error.
Would you mind sharing it?
The code is 5.2.3.1 and the use of pool replication has been for quite a while.
So am I correct in saying that I can create a new pool containing 1TB drives?
I have seen some other recommendations:
Same size tapes across VTL or at least in each pool.
No excessive free slots or tapes
Use expired tapes before scratch for better space usage.
How would you go about migrating the tapes to a new pool?
Regards,
Ignes
ignesingram
1 Rookie
•
59 Posts
0
June 9th, 2014 04:00
I am trying to get a change slot to upgrade to the latest code.
Are there any performance impact between using 1TB tapes compared to 200GB tapes?
Can directory replication be mixed with a newly created mtree replication pool in an existing VTL config?
If so - all the new pools can be created in this way to systematically remove the original "replication type"pools.
Cheers.
jbrooksuk
208 Posts
0
June 9th, 2014 04:00
I don't think you will see many articles that refer to the size of tape that you should use, personally I mostly agree with the other poster.
1TB is too large, 4TB is way too large. It would just mean that the tape is mounted for a long period of time until it is full, if your backup application idle timers are high then the tape may never eject for days.
100TB is possibly too small these days, maybe 200TB tapes are ideal but it depends on many factors, such as DDR model, storage available etc…
I would consider an upgrade to 5.4 if it was my DDR.
It’s the tape size you set that is important, the drive emulation (and it’s ‘real world/physical’ tape drive counterparts capacity and throughput specs) is pretty much academic other than for tape device drivers, I would use the newest drive emulation you can, so get the latest device drivers and set the tape size accordingly to your needs.
I would say, same size tapes in your system is just to keep it simple or your math can be complicated when calculating space used etc...
No excessive free slots or tapes just means that you are forced to re-use existing tapes rather than use new ones, again forcing space to be overwritten more frequently and existing tapes to be used/re-used rather than just sit there while a new tape is chosen.
Which I guess leads onto your final statement about using expired tapes before scratch tapes.
You can police this in the backup application but it’s simpler to keep your tape count down to a sensible amount for what you expect to need.
If you are going to reduce the tape size, which I personally would, then your tape count will go up to satisfy workload, in which case you will be into multiple tape pools to aim to keep under that “advised” 1000 tapes per pool, though your newer DDOS code is possibly better at handling this anyway.
Which type of replication method are you using (assume the latter?);
What is the difference between the VTL directory and Mtree type pool?
If you upgraded to 5.2 (not new install at 5.2) then you would have had to have chosen to upgrade to VTL/Mtree replication.
Without it, that would mean you have a backwards compatibility pool and you will still be using directory replication, which just isn’t as ‘slick’ as Mtree replication because Mtree uses snapshots for replication.
If you have low backup retention specified then maybe you could create a new pool(s) to use with smaller tapes for new backups and then delete the old larger tapes as they expire.
I would try to avoid migrating data via TSM, it will just add workload on both sides – it will dedupe well but it still needs to be “handled”, rehydrated, re-deduped etc...
I hope that helps but it’s a fairly large topic with many aspects that need to be looked at and understood.
Cheers, Jonathan
Carl-Adam_Lilje
32 Posts
1
June 11th, 2014 04:00
I would not expect any performance difference, but it will make sure that replication of a tape starts sooner as it is done upon close of the tape, which will be more frequent when using smaller tape sizes.
ShubhamMishra
40 Posts
0
June 12th, 2014 00:00
I read a while back that smaller a tape better the replication as one tape is considered as a file for replication, large tapes take time to replicate and can effect both RPO and RTO...
However it also depends on how replication is configured and ammount of bandwidth allocated..
We had 100 GB taoes in our environment and replication went fine for almost two years, even when we increased the capacity and amount of data written into the VTL both at source and destination data domains.