Replication task questions.

[gabsapao]

I need to ask a question about the behavior of the replication task.

In my environment there is a drawer with 12 3TB SAS disks, connected to any Tower Server with TrueNAS Core 13 via SAS cable.

Unfortunately, we didn't keep up with the growth of the drawer and it ran out of space, leaving 0GB free. In an attempt to reverse the situation, we thought of doing the "replication task" since it allows replicating zvol between pools, but we forgot that it first takes a snapshot and then sends it to the desired pool. NOTE: last snapshot was taken in ten /2022. Since he has 0GB of free space, is there a chance that the moment of the replica, as he couldn't take a snapshot, did he rollback/overwrites to send the exact moment from the source to the destination?

Because it is a file server, when we map the zvol via ISCSI, it is as if someone had rolled back, however as only me, and the owner of the company have access to the TrueNAS, neither of us did the rollback. The only chance is that the old snapshot overwrites the current state because it is unable to take an updated snapshot.

Thank you very much in advance.

Attachments with the drawer with 0GB and the snapshot we have.

 

[jgreco]

and it ran out of space, leaving 0GB free.

This is pretty horrifying. Please plan to use no more than 60% of a block storage volume in the future.

See:

Resource - The path to success for block storage

ZFS does two different things very well. One is storage of large sequentially-written files, such as archives, logs, or data files, where the file does not have the middle bits modified after creation. This is optimal for RAIDZ. It's what most...

www.truenas.com

 

[gabsapao]

This is pretty horrifying. Please plan to use no more than 60% of a block storage volume in the future.

See:

Resource - The path to success for block storage

ZFS does two different things very well. One is storage of large sequentially-written files, such as archives, logs, or data files, where the file does not have the middle bits modified after creation. This is optimal for RAIDZ. It's what most...

www.truenas.com

Yes, we are trying to adopt good practices in all our new and old implementations, including this attempt at the replication task, so that we had could redo the drawer.

 

[WI_Hedgehog]

Respectfully, your situation is dangerously vague (which is understandable given the severity of the situation).

If you snapshot the drive, any changes from that point forward consume:

1. The unmodified data at the time of the snapshot.
2. The changes to the data made after the time of the snapshot.

So, take the share out of service so no more writes occur. The following may be one of many possible solutions:

1. Copy at least some of the data off the volume (copy A).
2. Delete the snapshot so changes are made to the dataset.
3. Delete the data that was copied off the volume (possible because the snapshot was removed).
4. You now have breathing space to work with and can get employees back up and running.
5. Make a backup of (copy A), which at this point isn't a "copy" as it is the data.
6. Make a backup of the mostly-full volume.

At this point fragmentation is going to be severe on the existing volume, so perhaps you want to add a larger drive array to the server and replicate the volume there, restore (A).

When you're in the clear, check the S.M.A.R.T. status of the old drives and plan on how to use them to update your storage so each volume has sufficient free space.

---
You'll have to judge how applicable the above is to your situation.