Problem with replication task size of data

[Borja]

Hello,

I recently changed the com protocol of the replication task i have been doing for some years between two FreeNAS/TrueNAS system. So i changed from legacy to SSH.
Problem is the source system has 9.65TB of data occupied. But the replication task is trying to send more than 25TB. At first, i thought it was an error so i wait for the process to complete but it fills the destination system. I dont know what is sending because the capacity of the source NAS is 24TB and it trying to send more....
Any ideas whats happening, and how can i resolve this?

Thanks

 

[Borja]

Any suggestions about how to fix this problem?

 

[awasb]

[…{ Problem is the source system has 9.65TB of data occupied. But the replication task is trying to send more than 25TB. […]

How do you know that? Even with snaps it seems rather unlikely, that an amount of data gets sent that’s larger than 100% of the pool‘s size. I would guess the problem lies within the „presentation“ level.

Just for a start: please post the output of zpool list -v and zpool history -i.

 

[jhl]

Are you using deduplication or compression? This might make it possible to store more data than the pool's actual size, but the effect would only be this dramatic in very unusual cases.

If so are the settings on the destination pool different?

 

[Borja]

How do you know that? Even with snaps it seems rather unlikely, that an amount of data gets sent that’s larger than 100% of the pool‘s size. I would guess the problem lies within the „presentation“ level.

Just for a start: please post the output of zpool list -v and zpool history -i.

Im very sorry i have not received the notifications from the forum. Maybe i have them disabled.

This is my zpool list:

root@NAS2:~ # zpool list -vNAME SIZE ALLOC FREE CKPOINT EXPANDSZ

FRAG CAP DEDUP HEALTH ALTROOTBBD1Z2 29T 14.5T 14.5T - -
15% 50% 1.00x ONLINE /mnt raidz2 29T 14.5T 14.5T - -
15% 50% gptid/e4bdcef4-a432-11e5-a2fa-0cc47a6a5cfa - - - -
- - - gptid/e7493a4e-a432-11e5-a2fa-0cc47a6a5cfa - - - -
- - - gptid/e84cfee2-a432-11e5-a2fa-0cc47a6a5cfa - - - -
- - - gptid/e8dfd8e9-a432-11e5-a2fa-0cc47a6a5cfa - - - -
- - - gptid/e96ee28e-a432-11e5-a2fa-0cc47a6a5cfa - - - -
- - - gptid/e9fe6dcc-a432-11e5-a2fa-0cc47a6a5cfa - - - -
- - - gptid/ea89e682-a432-11e5-a2fa-0cc47a6a5cfa - - - -
- - - gptid/eb16a3a3-a432-11e5-a2fa-0cc47a6a5cfa - - - -
- - -
freenas-boot 14.5G 4.61G 9.89G - - - 31% 1.00x DEGRADED
mirror 14.5G 4.61G 9.89G - - - 31%
16957677190785387489 - - - - - - -
da2p2 - - - - - - -
root@NAS2:~ #

history -i is too big to post.
I know its real because it filled my destination pool completely and dont know how to fix it.

 

[Borja]

Are you using deduplication or compression? This might make it possible to store more data than the pool's actual size, but the effect would only be this dramatic in very unusual cases.

If so are the settings on the destination pool different?

I dont have dedup on and the pools settings are not different. It has been year since im doing this backup without any problem. The problem has started when i changed the transfer method from legacy to SSH.

What maybe i did wrong is that i modified the replication task instead of creating a new one. In the settings of the replication task i have recursive on and replicate from scratch if incremental is not possible.

Maybe i have to completely delete the destination pool and start a new replication task?

 

[Borja]

I deleted the destination dataset completely and the replication task on the source system and started from 0.
At first i tried the netcat transfer but it does not work so i changed to SSH and automatically started to send data.
Now is not sending 25TB but is sending 18TB as you can see in the picture attached.
I have not idea of what data is sending... but it would fill my destination NAS again...

I think this has to be some kind of error. Now i would like to upgrade to maybe fix the problem but i have to do it without a backup...

 

[awasb]

freenas-boot 14.5G 4.61G 9.89G - - - 31% 1.00x DEGRADED

What's up with your boot-pool?

history -i is too big to post.

Well, then, please attach it. (One period that fully covers a backup / replication rotation will be enough.) Without knowing your replication task settings one could only guess what's going on.

And more in general and more "strategically" ... as long as the data (amount) itself is dubious, there is no use of discussing types of transfer. ZFS blocks and the snap sizes won't change (in place) with different transfer tools. So: What exactly do you transfer? How many snaps do you keep? How much data is "changing" within your datasets? etc. etc.

 

[Borja]

What's up with your boot-pool?



Well, then, please attach it. (One period that fully covers a backup / replication rotation will be enough.) Without knowing your replication task settings one could only guess what's going on.

And more in general and more "strategically" ... as long as the data (amount) itself is dubious, there is no use of discussing types of transfer. ZFS blocks and the snap sizes won't change (in place) with different transfer tools. So: What exactly do you transfer? How many snaps do you keep? How much data is "changing" within your datasets? etc. etc.

Here it is. The snapshots has been configured for 3 weeks retention and 4h interval. I tried deleting some old manual snapshot that i have but still the same size...which i dont understand.

About the boot pool, its degraded because i have it mirrored but one of the usb drives has died. I have to replace it. Thanks!!

 

[Borja]

I have deleted all snapshot on the source system, because having the replication task working is the first priority than having the 3 week snapshots. I also deleted the snapshot task and the replication task. And i started from scratch.
Now, i only have one snapshot (2TB used and 8.72TB referenced) and is trying to send the same 18.x TB as before. I dont understand...