On Mon, Sep 18, 2017 at 12:23 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote: > 18.09.2017 05:31, Dave пишет: >> Sometimes when using btrfs send-receive, I get errors like this: >> >> ERROR: parent determination failed for <subvolume name> >> >> When this happens, btrfs send-receive backups fail. And all subsequent >> backups fail too. >> >> The issue seems to stem from the fact that an automated cleanup >> process removes certain earlier subvolumes. (I'm using Snapper.) >> >> I'd like to understand exactly what is happening so that my backups do >> not unexpectedly fail. >> > > You try to send incremental changes but you deleted subvolume to compute > changes against. It is hard to tell more without seeing subvolume list > with uuid/parent uuid.
I do not have a current subvolume list to provide UUID's. To ensure integrity of my backups, I was forced to delete all backup snapshots and start over. (After this initial parent determination error, my attempted solution created a new problem related to Received UUID's, so removing all backups was the best solution in the end.) For my understanding, what are the restrictions on deleting snapshots? What scenarios can lead to "ERROR: parent determination failed"? After all, it should not be necessary to retain every snapshot ever made. We have to delete snapshots periodically. In my case, I still retained every snapshot on the target volume. None had ever been deleted (yet). And I also retained around 30 recent snapshots on the source, according to the snapper timeline cleanup config. Yet I still ran into "ERROR: parent determination failed". > >> In my scenario, no parent subvolumes have been deleted from the >> target. Some subvolumes have been deleted from the source, but why >> does that matter? I am able to take a valid snapshot at this time and >> every snapshot ever taken continues to reside at the target backup >> destination (seemingly meaning that a parent subvolume can be found at >> the target). >> >> This issue seems to make btrfs send-receive a very fragile backup >> solution. > > btrfs send/receive is not backup solution - it is low level tool that > does exactly what it is told to do. You may create backup solution that > is using btrfs send/receive to transfer data stream, but then do not > blame tool for incorrect usage. > > To give better advice how to fix your situation you need to describe > your backup solution - how exactly you select/create snapshots. I use snap-sync to create and send snapshots. GitHub - wesbarnett/snap-sync: Use snapper snapshots to backup to external drive https://github.com/wesbarnett/snap-sync > > I hope, instead, there is some knowledge I'm missing, that >> when learned, will make this a robust backup solution. >> >> Thanks >> -- -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
