I have pool URANUS that’s replicating one specific dataset (rtorrent/.session) to JUPITER/backrtorrentsession.
Aside from that, I have auto snapshots on JUPITER and I want to replicate JUPITER to BJUPITER pool, as close as possible.
For some reason, I’m unable to do this since I started the rtorrent/.session replication.
How do I fix this? This is my data backup mechanism.
I attached the error output of the task, which is configured in the following way:
373.txt (8.6 KB)
cannot send JUPITER@francesco-fix1-202409042341 recursively: snapshot JUPITER/bakrtorrentsession@francesco-fix1-202409042341 does not exist\nwarning: cannot send ‘JUPITER@francesco-fix1-202409042341’: backup failed\ncannot receive: failed to read from stream")
Does your snapshot continains all childs (is recursive?)
The francesco-fix1 yes, I was thinking maybe JUPITER/bakrtorrentsession did not exist when I took francesco-fix1-202409042341. I’m not 100% confident, I definitely created the dataset on that day, but I don’t remember the exact time.
I know for a fact that I do have only 2 francesco-fix1 snapshots on JUPITER and that the first one does NOT have JUPITER/bakrtorrentsession because I took it before the dataset existed, then I took the second one after truenas was upgraded and after that dataset was created.
Is my only option to replicate from scratch? I can’t seem to be able to figure this out.
I would be ok discarding all the snapshots in the backup except the latest one.
I figured it out. It’s not exactly clear to me how what I did corrects this, but let me explain:
I was wrong and francesco-fix1-202409042341 does not contain all child, JUPITER/bakrtorrentsession is missing.
What I did was create a snapshot named francesco-fix1-202409042341 for that dataset, even if it’s ahead in time.
After I did that, the replication proceeded smoothly.
What are the consequences of what I did?
You now have a snapshot in common between the two systems that the replication system can fall back to in case something wacky happens with future snapshots?
Is it? The snapshot was taken in the future in comparison to others, that’s why I felt uncomfortable.
This same trick fixed my other pool, which makes me very happy.
Am I right in noticing that replication task does not preserve file timestamps?
Really don’t know how to answer. If i understand well, you create a manual snap naming It how the replication need…
Everytime i messed up with replication backup, i just always have started from 0… safer from my pov
Someone more ZFS-guru-y confirm my knowledge, but a snapshot basically includes a point-in-time set of blocks of what the pool/dataset contained at the time of said snapshot, so it doesn’t matter what other snapshots have or don’t have, just whether data is included in them (including potential child datasets et al).
When you replicate said snapshot, assuming it’s possible to do so, then both pools that contain that snapshot will effectively contain that same data. There is nothing to do with “this came before that” it’s just “these blocks are what I’m listing”.
Remember ZFS is a copy-on-write system, which is why snapshots are so powerful: Modifying or adding more data blocks doesn’t change those blocks, but get sent into new blocks, which (if you then take another snapshot) will be included in the next snapshot (or excluded from any prior snapshot).
It should…? Again, it’s copying the data blocks, nothing should be modified when replicating a snapshot as it’s just sending over the blocks represented in the snapshot (and if sending over a future snapshot, just the difference in blocks between the two).
What do you mean it doesn’t preserve timestamps?
Thank you for the answer, well that gives me some reassurance.
By not preserving the timestamps I mean that if I had a file named foo.jpg with creation time September 4th which was missing on the target, when I replicated it on the target the creation time was September 5th.
I downloaded the file and opened it in an image viewer and it was identical (visually at least), so I was ok with the different creation time, but it did feel weird to me.
Yeah that doesn’t sound right. For all intents and purposes the destination system would be identical.
Though it’s possible ZFS is tracking birth times (aka creation) differently. Either way, the underlying data should still be identical so it might just be a curiosity.
