ambiser
/
btrbk
mirror of https://github.com/digint/btrbk
9
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

btrbk: disallow unrelated (by parent_uuid) parents for btrfs-send if incremental=strict 

Makes sure that if, for whatever reason, a subvolume having correct
btrbk name scheme does NOT share any extents with previous snapshots
is never used as parent.

Note that if a related parent is found, the unrelated closest
older/newer (by btrbk timestamp) subvolumes are still added as clone
sources.
pull/274/head
Axel Burri 2019-04-09 22:15:18 +02:00
parent c407d41db2
commit 318126b831
2 changed files with 22 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
btrbk
View File

@ -3107,6 +3107,7 @@ sub get_best_parent($$$;@)
my $ret_clone_src = $opts{clone_src};
my $ret_clone_src_extra = $opts{clone_src_extra};
my $ret_target_parent_node = $opts{target_parent_node};
my $strict_related = $opts{strict_related};
TRACE "get_best_parent: resolving best common parent for subvolume: $svol->{PRINT} (droot=$droot->{PRINT})";
@ -3229,6 +3230,12 @@ sub get_best_parent($$$;@)
DEBUG("No common parents of \"$svol->{PRINT}\" found in src=\"$resolve_sroot->{PRINT}/\", target=\"$resolve_droot->{PRINT}/\"");
return undef;
}
if($strict_related && (not scalar(@c_related))) {
# all parents come from c_snapdir (btrbk_direct_leaf), no relations by parent_uuid found
WARN "No related common parent found (by parent_uuid relationship) for: $svol->{PRINT}";
WARN "Hint: setting option \"incremental\" to \"yes\" (instead of \"strict\") will use parent: " . join(", ", map { $_->[0]{PRINT} } @parent);
return undef;
}
my @extra_clones;
foreach my $cc (@c_related_older, @c_related_newer, grep { not exists($c_rel_id{$_->[0]{node}{id}}) } (@c_snapdir_older, @c_snapdir_newer)) {
@ -4023,6 +4030,7 @@ sub macro_archive_target($$$;$)
{
my ($clone_src, $clone_src_extra, $target_parent_node);
my $parent = get_best_parent($svol, $sroot, $droot,
strict_related => 0,
clone_src => \$clone_src,
clone_src_extra => \$clone_src_extra,
target_parent_node => \$target_parent_node);
@ -6157,6 +6165,7 @@ MAIN:
INFO "Creating subvolume backup (send-receive) for: $child->{PRINT}";
my ($clone_src, $clone_src_extra, $target_parent_node);
my $parent = get_best_parent($child, $snaproot, $droot,
strict_related => ((config_key($droot, "incremental") // "") eq "strict"),
clone_src => \$clone_src,
clone_src_extra => \$clone_src_extra,
target_parent_node => \$target_parent_node);

15
doc/btrbk.conf.5.asciidoc
View File

@ -150,9 +150,20 @@ Note that using ``long-iso'' has implications on the scheduling, see
snapshot creation). Defaults to ``always''.
*incremental* yes|no|strict::
If set, incremental backups are created. If set to ``strict'',
non-incremental (initial) backups are never created. Defaults to
``yes''.
non-incremental (initial) backups are never created, and
incremental backups are restricted to 'related parents' (by
parent-uuid relationship). Defaults to ``yes''.
+
--
Note that even if the parent-uuid chain is broken, snapshots and
backups can still share data (which is especially true for backups
created with 'incremental' option enabled), and are perfectly suitable
as parents for incremental send-receive operations. But as btrbk can
not be certain about this, such operations are disallowed in
"incremental strict" mode.
--
=== Grouping Options