On Thursday, June 13, 2019 11:55:05 PM EDT Chris Murphy wrote: > On Thu, Jun 13, 2019 at 3:23 PM Eric Mesa <eric@xxxxxxxxxxxx> wrote: > > On Thursday, June 13, 2019 2:26:10 AM EDT Andrei Borzenkov wrote: > > > All your snapshots on source have the same received_uuid (I have no idea > > > how is it possible). If received_uuid exists, it is sent to destination > > > instead of subvolume UUID to identify matching snapshot. All your backup > > > sbapshots on destination also have the same received_uuid which is > > > matched against (received_)UUID of source subvolume. In this case > > > receive command takes the first found subvolume (probably the most > > > recent, i.e. with the smallest generation number). So you send > > > differential stream against one subvolume and this stream is applied to > > > another subvolume which explains the error. > > > > Yup. Any idea of how to fix? > > Maybe 'cp -a --relink' into a new subvolume on the source. It won't > complete immediately like a snapshot. But it'll complete way faster > than a normal data copy. From that point, this new subvolume becomes > "master" where all changes occur, and all the other snapshots are made > from it. > > Also, you should do incrementals between the most recent two > snapshots. i.e. the snapshot that follows -p should be the snapshot > most recently successfully received on the destination. That > represents the least amount of increment needed to update the > destination. It will work the way you're doing it now, with -p being > an older snapshot, but you're unnecessarily sending a lot more data > every time. Just in case anyone is searching the net with the same issue, I want to confirm that this worked. Ever since moving to a clean /home subvol (didn't have a recieved_UUID) everything has worked perfectly with respect to the issue I'd emailed the mailing list about. -- -- Eric Mesa
Attachment:
signature.asc
Description: This is a digitally signed message part.
