This is an issue I've reported: http://bugs.dragonflybsd.org/issues/2915
My way around this is to create the new master and use cpdup to copy the PFS slave to it. Tim On Mon, Oct 29, 2018 at 6:22 AM Aleksej Lebedev <[email protected]> wrote: > Hi! > > Recently my 5T hard drive broke. It contained among other things a > master PFS that was backed up to a remote host. > > I replaced broken hard drive, formatted it and run hammer mirror-copy > from the remote pfs. After that I upgraded the freshly copied PFS to > master > and now I can't set up the backup process again. The command "hammer > mirror-stream" simply doesn't do anything. > > Both my new master PFS and old backup seem to work OK and I can even > mirror-stream from them to other places. But I can't mirror-stream from > master to slave. > I checked sync-end-tid on both of them and noticed that for some reason > the TID of my new master is a bit behind the one on my slave. > > So I guess I somehow a few changes from my backup were not commited to > my new harddrive. The problem is I already upgraded this PFS to master > and even made some changes on it (just for testing, I don't mind loosing > them). > > I realize that I can easily delete the master PFS, re-mirror it again > from my backup and make sure it has the same sync-end-tid before > upgrading it to master, but I would like to avoid it because the PFS is > very large. > > My question: is it possible to roll-back a PFS (master or slave) a few > transactions back? > > I noticed that "hammer pfs-update" allows to simply change sync-end-tid, > but since I don't understand what it is made for I am in doubt. > Especially because the man page states "Manually modifying this field is > dangerous and can result in a broken mirror." > > Is there a way to roll-back a PFS or I have to re-mirror it from my > backup again? > > (I also now that I can do a local mirror-stream from my new master to > separate PFS, stop it right before the end and then finish mirroring > from my backup, but I it requires a lot of copying anyway, though local > is better than remote, which I would like to avoid.) > > -- > Aleksej Lebedev >
