For others' reference
I have fixed this problem at least twice by the following steps:
List out your snapshots:
I chose to use the second-to-last on the destination as I believed it to be a complete snapshot.
@auto-YYYYMMDD.tttt-Nw is the specific snapshot you're looking at.
Get that snapshot's attributes if you like:
On the destination:
On the source:
FreeNAS was able to then send all of the snapshots until it became current. This may be bad if your snapshots are very large compared to your link,
This can be with a manual snapshot (I already had a server as a destination that I was backing up to manually).
Rather than doing a full reset I named my latest snapshot appropriately, setup the replication to run over SSH etc. and then set these properties and the replication started from that point on.
I hope this is helpful to someone else.
I have fixed this problem at least twice by the following steps:
List out your snapshots:
zfs list -t snapshot
Choose a snapshot on the destination server that exists on the sending server.I chose to use the second-to-last on the destination as I believed it to be a complete snapshot.
@auto-YYYYMMDD.tttt-Nw is the specific snapshot you're looking at.
Get that snapshot's attributes if you like:
zfs get all destinationpool/dataset@auto-20141015.1200-4w
On the destination:
zfs freenas:state=NEW destinationpool/dataset@auto-20141015.1200-4w
On the source:
zfs freenas:state=LATEST sourcepool/dataset@auto-20141015.1200-4w
FreeNAS was able to then send all of the snapshots until it became current. This may be bad if your snapshots are very large compared to your link,
This can be with a manual snapshot (I already had a server as a destination that I was backing up to manually).
Rather than doing a full reset I named my latest snapshot appropriately, setup the replication to run over SSH etc. and then set these properties and the replication started from that point on.
I hope this is helpful to someone else.
