Target replication server db size

[vilius.m]

Hello,

TSM 7.1.3

Lets say we have tsm db size 10Gb, we deduplicate data and now db size is 200Gb.
Now we replicate all this data to storage pools where deduplication is disabled.

What target replication server db size we should expect - around 10G or 200G ?

Thanks,
Vilius M.

 

[marclant]

Hard to tell, because the replication will add overhead too. The target will certainly be smaller than the source because the data is not deduplicated, but that doesn't mean it will be 10GB either. You certainly don't want to shoot yourself in the foot and have a database too small on the target. You can obviously add more space later.

The manual doesn't cover the overhead of replication. It probably isn't much, just an additional flag or something like that.

Count the number of objects in the backups and archives table:

select count(*) from backups
select count(*) from archives

Then use this to estimate the size on the target: http://www-01.ibm.com/support/knowl...rv.install/t_srv_inst_db_space_files-aix.html

I'd probably then double that number for growth. Doesn't look like you would need much space anyway, if your deduplicated DB is only 200GB, it's tiny in comparisons to many who have 2 or 3TB size DB.

 

[moon-buddy]

Lets say we have tsm db size 10Gb, we deduplicate data and now db size is 200Gb.

I don't follow your numbers.

If your DB is just 10 GB and after deduplication it is now 200 GB, then why apply deduplication? The idea of deduplication is to reduce the footprint.

Why the jump to 200 GB? Or, do mean 200 MB?

 

[marclant]

then why apply deduplication?

The DB increases with dedup, the storage pool shrinks. The savings in the stgpool far outweigh the increase in the DB.

 

[moon-buddy]

The DB increases with dedup, the storage pool shrinks. The savings in the stgpool far outweigh the increase in the DB.

Still does not seem correct. That is a 20X increase.

I understand that this is a logical number and the real storage occupancy is far less than this. The question is how much is the real storage occupancy number? If this takes up the same as 10 GB on the real storage, then why use TSM deduplication as this does not provide any advantage?

 

[marclant]

You are right, the increase seems too steep. I question the original 10GB number too if the end result is 200GB. Here is some example of the DB cost of dedup:

Now, this doesn't include the size of the DB, just by how much the DB would grow if deduplicating that much data.