[PATCH] btrfs-progs: optionally enforce chroot for btrfs receive
This patch forces btrfs receive to issue chroot before
parsing the btrfs stream using command-line flag -C
to confine the process and minimize damage that could
be done via malicious btrfs stream.
Signed-off-by: Lauri Võsandi lauri.vosa...@gmail.com
---
cmds-receive.c | 37 -
1 file changed, 28 insertions(+), 9 deletions(-)
diff --git a/cmds-receive.c b/cmds-receive.c
index 44ef27e..73bd88b 100644
--- a/cmds-receive.c
+++ b/cmds-receive.c
@@ -61,6 +61,7 @@ struct btrfs_receive
char *root_path;
char *dest_dir_path; /* relative to root_path */
char *full_subvol_path;
+ int dest_dir_chroot;
struct subvol_info *cur_subvol;
@@ -867,14 +868,27 @@ static int do_receive(struct btrfs_receive *r, const char
*tomnt, int r_fd,
goto out;
}
- /*
-* find_mount_root returns a root_path that is a subpath of
-* dest_dir_full_path. Now get the other part of root_path,
-* which is the destination dir relative to root_path.
-*/
- r-dest_dir_path = dest_dir_full_path + strlen(r-root_path);
- while (r-dest_dir_path[0] == '/')
- r-dest_dir_path++;
+ if (r-dest_dir_chroot) {
+ if (chroot(dest_dir_full_path)) {
+ ret = -errno;
+ fprintf(stderr,
+ ERROR: failed to chroot to %s, %s\n,
+ dest_dir_full_path,
+ strerror(-ret));
+ goto out;
+ }
+ if(chdir(/)) {
+ ret = -errno;
+ fprintf(stderr,
+ ERROR: failed to chdir to /, %s\n,
+ strerror(-ret));
+ }
+ if (g_verbose = 1) {
+ fprintf(stderr, chrooted to %s\n,
+ dest_dir_full_path);
+ }
+ r-root_path = r-dest_dir_path = strdup(/);
+ }
ret = subvol_uuid_search_init(r-mnt_fd, r-sus);
if (ret 0)
@@ -940,6 +954,7 @@ int cmd_receive(int argc, char **argv)
r.write_fd = -1;
r.dest_dir_fd = -1;
r.explicit_parent = NULL;
+ r.dest_dir_chroot = 0;
while (1) {
int c;
@@ -948,7 +963,7 @@ int cmd_receive(int argc, char **argv)
{ NULL, 0, NULL, 0 }
};
- c = getopt_long(argc, argv, evf:p:, long_opts, NULL);
+ c = getopt_long(argc, argv, Cevf:p:, long_opts, NULL);
if (c 0)
break;
@@ -962,6 +977,9 @@ int cmd_receive(int argc, char **argv)
case 'e':
r.honor_end_cmd = 1;
break;
+ case 'C':
+ r.dest_dir_chroot = 1;
+ break;
case 'E':
max_errors = arg_strtou64(optarg);
break;
@@ -1014,6 +1032,7 @@ const char * const cmd_receive_usage[] = {
in the data stream. Without this option,,
the receiver terminates only if an error,
is recognized or on EOF.,
+ -C Confine the process to mount using chroot,
--max-errors N Terminate as soon as N errors happened while,
processing commands from the send stream.,
Default value is 1. A value of 0 means no limit.,
--
1.9.1
--
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
[PATCH] btrfs-progs: optionally enforce chroot for btrfs receive
This patch forces btrfs receive to issue chroot before
parsing the btrfs stream using command-line flag -C
to confine the process and minimize damage that could
be done via malicious btrfs stream.
Signed-off-by: Lauri Võsandi lauri.vosa...@gmail.com
---
cmds-receive.c | 37 -
1 file changed, 28 insertions(+), 9 deletions(-)
diff --git a/cmds-receive.c b/cmds-receive.c
index a1c72f9..366a63a 100644
--- a/cmds-receive.c
+++ b/cmds-receive.c
@@ -61,6 +61,7 @@ struct btrfs_receive
char *root_path;
char *dest_dir_path; /* relative to root_path */
char *full_subvol_path;
+ int dest_dir_chroot;
struct subvol_info *cur_subvol;
@@ -858,14 +859,27 @@ static int do_receive(struct btrfs_receive *r, const char
*tomnt, int r_fd,
goto out;
}
- /*
-* find_mount_root returns a root_path that is a subpath of
-* dest_dir_full_path. Now get the other part of root_path,
-* which is the destination dir relative to root_path.
-*/
- r-dest_dir_path = dest_dir_full_path + strlen(r-root_path);
- while (r-dest_dir_path[0] == '/')
- r-dest_dir_path++;
+ if (r-dest_dir_chroot) {
+ if (chroot(dest_dir_full_path)) {
+ ret = -errno;
+ fprintf(stderr,
+ ERROR: failed to chroot to %s, %s\n,
+ dest_dir_full_path,
+ strerror(-ret));
+ goto out;
+ }
+ if(chdir(/)) {
+ ret = -errno;
+ fprintf(stderr,
+ ERROR: failed to chdir to /, %s\n,
+ strerror(-ret));
+ }
+ if (g_verbose = 1) {
+ fprintf(stderr, chrooted to %s\n,
+ dest_dir_full_path);
+ }
+ r-root_path = r-dest_dir_path = strdup(/);
+ }
ret = subvol_uuid_search_init(r-mnt_fd, r-sus);
if (ret 0)
@@ -930,6 +944,7 @@ int cmd_receive(int argc, char **argv)
r.mnt_fd = -1;
r.write_fd = -1;
r.dest_dir_fd = -1;
+ r.dest_dir_chroot = 0;
while (1) {
int c;
@@ -938,7 +953,7 @@ int cmd_receive(int argc, char **argv)
{ NULL, 0, NULL, 0 }
};
- c = getopt_long(argc, argv, evf:, long_opts, NULL);
+ c = getopt_long(argc, argv, Cevf:, long_opts, NULL);
if (c 0)
break;
@@ -952,6 +967,9 @@ int cmd_receive(int argc, char **argv)
case 'e':
r.honor_end_cmd = 1;
break;
+ case 'C':
+ r.dest_dir_chroot = 1;
+ break;
case 'E':
max_errors = arg_strtou64(optarg);
break;
@@ -1001,6 +1019,7 @@ const char * const cmd_receive_usage[] = {
in the data stream. Without this option,,
the receiver terminates only if an error,
is recognized or on EOF.,
+ -C Confine the process to mount using chroot,
--max-errors N Terminate as soon as N errors happened while,
processing commands from the send stream.,
Default value is 1. A value of 0 means no limit.,
--
1.9.1
--
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
system frozen during send/receive
Hi. As mentioned before on the list, I'm just playing with send/receive. The first huge disappointment (after copying already hundreds of gigabytes for hours) was, that when I Ctrl-Z the sending/receiving pipe (to give the disks a little bit of rest to cool down) can resuming it (fg) it immediately exited with an crc32 error in the command itself (i.e. not a data block error, at least I guess, since this would be in the syslog, wouldn't it?). As if stopping that wasn't allowed to be stopped... nothing of which would be anywhere documented :-( I don't recall the exact wording since shortly afterwards the following happened: I deleted the (obviously broken) subvolume at the target fs, did some proper cursing and started over from scratch with the copying. A minute or so later, the system froze. SysRq-RESIUB still worked though. The following found itself in the syslog: Apr 18 17:03:04 heisenberg kernel: [425939.974472] [ cut here ] Apr 18 17:03:04 heisenberg kernel: [425939.974495] kernel BUG at /build/linux-gzeV2n/linux-3.19.3/fs/btrfs/inode.c:3142! Apr 18 17:03:04 heisenberg kernel: [425939.974517] invalid opcode: [#1] SMP Apr 18 17:03:04 heisenberg kernel: [425939.974531] Modules linked in: nls_utf8 isofs sr_mod cdrom udp_diag tcp_diag inet_diag vhost_net vhost macvtap macvlan xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat xt_tcpudp bridge stp llc tun ccm binfmt_misc seqiv algif_skcipher md4 algif_hash af_alg cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 deflate ctr twofish_generic twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_aesni_avx_x86_64 camellia_x86_64 serpent_avx_x86_64 serpent_sse2_x86_64 xts serpent_generic blowfish_generic blowfish_x86_64 blowfish_common cast5_avx_x86_64 cast5_generic cast_common des_generic cbc cmac xcbc rmd160 sha512_ssse3 sha512_generic ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables sha256_ssse3 sha256_generic hmac crypto_null xt_policy ipt_REJECT nf_reject_ipv4 af_key xt_comment xfrm_algo nf_conntrack_ipv4 nf_defrag_ipv4 xt_multiport xt_conntrack nf_conntrack iptable_filter ip_tables x_tables joydev rtsx_pci_ms rtsx_pci_sdmmc mmc_core memstick iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul evdev ghash_clmulni_intel psmouse serio_raw pcspkr ecb sg uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media btusb bluetooth arc4 iwldvm mac80211 iwlwifi rtsx_pci cfg80211 rfkill tpm_tis tpm 8250_fintek snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic battery processor fujitsu_laptop snd_hda_intel snd_hda_controller snd_hda_codec ac i2c_i801 snd_hwdep snd_pcm lpc_ich mfd_core snd_timer snd soundcore shpchp i915 button video drm_kms_helper drm e1000e thermal_sys i2c_algo_bit i2c_core ptp mei_me pps_core mei loop fuse parport_pc ppdev lp parport autofs4 dm_crypt dm_mod md_mod btrfs xor raid6_pq ext4 crc16 mbcache jbd2 uhci_hcd usb_storage sd_mod crc32c_intel aesni_intel ahci libahci aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd xhci_pci libata ehci_pci xhci_hcd ehci_hcd scsi_mod usbcore usb_common Apr 18 17:03:04 heisenberg kernel: [425939.975271] CPU: 0 PID: 8008 Comm: btrfs-cleaner Tainted: GW 3.19.0-trunk-amd64 #1 Debian 3.19.3-1~exp1 Apr 18 17:03:04 heisenberg kernel: [425939.975299] Hardware name: FUJITSU LIFEBOOK E782/FJNB23E, BIOS Version 1.11 05/24/2012 Apr 18 17:03:04 heisenberg kernel: [425939.975323] task: 880409bc8ca0 ti: 88024b54 task.ti: 88024b54 Apr 18 17:03:04 heisenberg kernel: [425939.975344] RIP: 0010:[a03138b3] [a03138b3] btrfs_orphan_add+0x103/0x1d0 [btrfs] Apr 18 17:03:04 heisenberg kernel: [425939.975385] RSP: 0018:88024b543c88 EFLAGS: 00010286 Apr 18 17:03:04 heisenberg kernel: [425939.975400] RAX: ffe4 RBX: 88040ab96000 RCX: 618b Apr 18 17:03:04 heisenberg kernel: [425939.975419] RDX: 618b RSI: 0004 RDI: 880028fbb138 Apr 18 17:03:04 heisenberg kernel: [425939.975439] RBP: 880101d331e8 R08: 8800889a73a0 R09: 880130738ec0 Apr 18 17:03:04 heisenberg kernel: [425939.975458] R10: R11: R12: 88040ab96458 Apr 18 17:03:04 heisenberg kernel: [425939.975478] R13: 88011cd9fe88 R14: 0001 R15: 0001 Apr 18 17:03:04 heisenberg kernel: [425939.975498] FS: () GS:88041e20() knlGS: Apr 18 17:03:04 heisenberg kernel: [425939.975520] CS: 0010 DS: ES: CR0: 80050033 Apr 18 17:03:04 heisenberg kernel: [425939.975536] CR2: 7ffbb4092000 CR3: 01813000 CR4: 001407f0 Apr 18 17:03:04 heisenberg
Re: how to clone a btrfs filesystem
On Sat, 18 Apr 2015, Christoph Anton Mitterer cales...@scientia.net wrote: On Sat, 2015-04-18 at 04:24 +, Russell Coker wrote: dd works. ;) There are patches to rsync that make it work on block devices. Of course that will copy space occupied by deleted files too. I think both are not quite the solutions I was looking for. I know, but I don't think what you want is possible at this time. Guess for dd this is obvious, but for rsync I'd also loose all btrfs features like checksum verifications,... and even if these patches you mention would make it work on block devices, I'd guess it would at least need to read everything, it would not longer be a merge into another filesystem (perhaps I shouldn't have written clone)... and the target block device would need to have at least the size of the origin. An rsync on block devices wouldn't lose BTRFS checksums, you could run a scrub on the target at any time to verify them. For a dd or anything based on that the target needs to be at least as big as the source. But typical use of BTRFS for backup devices tends to result in keeping as many snapshots as possible without running out of space which means that no matter how you were to copy it the target would need to be as big. Can't one do something like the following: 1) The source fs has several snapshots and subvols. The target fs is empty (the first time). For the first time populating the target fs: 2) Make ro snapshots of all non-ro snapshots and subvols on the source-fs. 3) Send/receive the first of the ro snapshots to the target fs, with no parent and no clone-src. 4) Send/receive all further ro snapshots to the target fs, with no parents, but each time specifying one further clone-src (i.e. all that have already been sent/received) so that they're used for reflinks and so on 5) At the end somehow make rw-subvols from the snapshots/subvols that have been previously rw (how?). Sure, for 5 I believe you can make a rw snapshot of a ro subvol. Does that sound as if it would somehow work like that? Especially would it preserve all the reflink statuses and everything else (sparse files, etc.) Yes, but it would take a bit of scripting work. Some additional questions: a) Can btrfs send change anything(!) on the source fs? b) Can one abort (Ctrl-C) a send and/or receive... and make it continue at the same place were it was stopped? A yes, B I don't know. Also I'm not personally inclined to trust send/recv at this time. I don't think it's had a lot of testing. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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
Re: how to clone a btrfs filesystem
On Sat, 2015-04-18 at 10:20 -0600, Chris Murphy wrote: Make the source a seed device, add new device, delete seed. Once that completes, unmount, unset btrfs seed, and now the two devices are separate fs volumes each with unique UUID. There may still be bugs with seed device, it's been maybe 6 months since I last checked. Hmm but that also modifies the source fs, at least the seed device part, right? Given that all this apparently contains still bugs, I'd have rather kept the source fs read only. Also, AFAIU this would work only once then and I wouldn't be able to do incremental backups, would I? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: how to clone a btrfs filesystem
On Fri, Apr 17, 2015 at 5:08 PM, Christoph Anton Mitterer cales...@scientia.net wrote: Hey. I've seen that this has been asked some times before, and there are stackoverflow/etc. questions on that, but none with a really good answer. How can I best copy one btrfs filesystem (with snapshots and subvolumes) into another, especially with keeping the CoW/reflink status of all files? And ideally incrementally upgrade it later (again with all snapshots/subvols, and again not loosing the shared blocks between these files). Make the source a seed device, add new device, delete seed. Once that completes, unmount, unset btrfs seed, and now the two devices are separate fs volumes each with unique UUID. There may still be bugs with seed device, it's been maybe 6 months since I last checked. -- Chris Murphy -- 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
Re: how to clone a btrfs filesystem
Chris Murphy li...@colorremedies.com schrieb: On Sat, Apr 18, 2015 at 10:09 AM, Kai Krakow hurikha...@gmail.com wrote: You could simply btrfs device add the new device, then btrfs device del the old device... That wipes the btrfs signature (maybe the entire superblock, I'm not sure) from the deleted device. It needs to be a seed device first to prevent that, which makes it ro. Yeah, I figured I forgot about the copy requirement Cristoph mentioned... My suggestions only works for cloning if you want to actually migrate from the old to the new device, and no longer use the old one. I wonder if one could split mirrors in btrfs... Read: btrfs device add the new device, set the raid policy for data, meta data, and system to raid-1, balance, and then unmount and detach one of the devices. I'm not sure how to get out of the degraded state then. Is it possible to simply resort from raid-1 to single raid policy again and remove the missing device from the pool? Regarding data, it should contain everything needed for running the filesystem - so it should have no problem here. I guess there's one caveat: The signature of both devices will then indicate they are belonging to the same pool, making it impossible to ever attach those to the same system again without causing trouble for your data. If one could change that to make both devices distinct filesystems, it could be used to implement a btrfs filesystem clone call. -- Replies to list only preferred. -- 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
Re: how to clone a btrfs filesystem
Christoph Anton Mitterer cales...@scientia.net schrieb: Hey. I've seen that this has been asked some times before, and there are stackoverflow/etc. questions on that, but none with a really good answer. How can I best copy one btrfs filesystem (with snapshots and subvolumes) into another, especially with keeping the CoW/reflink status of all files? And ideally incrementally upgrade it later (again with all snapshots/subvols, and again not loosing the shared blocks between these files). send/receive apparently also works for just one subvolume,... and documentation is quite sparse :-/ You could simply btrfs device add the new device, then btrfs device del the old device... It won't create a 1:1 clone, if that is your intention. But it will migrate all your data over to the new device (even a bigger/smaller one), keeping shared extents (CoW/reflink status), generation numbers, file system uid, label, each subvolume, etc... And it can be done while the system is running. It looks like this way fulfills all your requirements. That same way you can later incrementally update it again. -- Replies to list only preferred. -- 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
Re: how to clone a btrfs filesystem
Kai Krakow hurikha...@gmail.com schrieb: Christoph Anton Mitterer cales...@scientia.net schrieb: Hey. I've seen that this has been asked some times before, and there are stackoverflow/etc. questions on that, but none with a really good answer. How can I best copy one btrfs filesystem (with snapshots and subvolumes) into another, especially with keeping the CoW/reflink status of all files? And ideally incrementally upgrade it later (again with all snapshots/subvols, and again not loosing the shared blocks between these files). send/receive apparently also works for just one subvolume,... and documentation is quite sparse :-/ You could simply btrfs device add the new device, then btrfs device del the old device... It won't create a 1:1 clone, if that is your intention. But it will migrate all your data over to the new device (even a bigger/smaller one), keeping shared extents (CoW/reflink status), generation numbers, file system uid, label, each subvolume, etc... And it can be done while the system is running. It looks like this way fulfills all your requirements. That same way you can later incrementally update it again. BTW: I've done that when migrating my 3-device btrfs pool to bcache. I simply removed one device, reformatted with bcache, then added it. I repeated those steps for each device. It took a while (like 24 hours) but it worked. In the end I just did a balance to rebalance all 3 devices. That last step is not needed if you are migrating only one device. As a safety measurement I did a backup first, then ran btrfs check to ensure file system integrity, and did start into the rescue shell to have only a minimum set of processes running. Due to a bug in the Intel graphics stack the system froze sometimes, and I didn't want that to happen during data migration. -- Replies to list only preferred. -- 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
Re: how to clone a btrfs filesystem
On Sat, Apr 18, 2015 at 10:09 AM, Kai Krakow hurikha...@gmail.com wrote: You could simply btrfs device add the new device, then btrfs device del the old device... That wipes the btrfs signature (maybe the entire superblock, I'm not sure) from the deleted device. It needs to be a seed device first to prevent that, which makes it ro. -- Chris Murphy -- 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
Re: how to clone a btrfs filesystem
Russell Coker posted on Sun, 19 Apr 2015 01:02:42 +1000 as excerpted: Some additional questions: a) Can btrfs send change anything(!) on the source fs? b) Can one abort (Ctrl-C) a send and/or receive... and make it continue at the same place were it was stopped? A yes, B I don't know. More directly on A, btrfs send creates a read-only snapshot and sends it, so the filesystem isn't changing out from under it as it sends. So that's what it changes on the source filesystem. AFAIK, nothing else. For B, my use-case doesn't include send/receive, so I don't know, directly, either. But due to the way it works, assuming an aborted send/ receive doesn't get automatically cleaned up (I simply don't know that, and I'm not bothering to look it up, but it should be documented if it does), it should at minimum be possible to include the aborted version as a parent or reference on each end, such that if any data was sent in the aborted send/receive, it shouldn't have to be sent again, only a metadata reference to it will need to be sent. Also I'm not personally inclined to trust send/recv at this time. I don't think it's had a lot of testing. Based on posts from people using it here, as well as watching the patches, etc, going by, I'd say that given a send/receive that has completed without error, it should be reliably golden. There continue to be various corner-case bugs where it doesn't always work, but in that case it should reliably error on one side or the other. A very simple example of the type of corner-case that still causes problems, tho this one should work, it's the much more complex ones that sometimes don't, is where the original filesystem had /dir/suba/subb/, but that nesting was reversed to /dir/subb/suba/. That's the general sort of thing that can still cause problems, altho simple example shouldn't, but obviously, it can only be a problem on later incrementals that reference a parent with a tree that has gone inside out, so to speak, since the parent send. But again, if the process works without error on both sides, then the result should be golden, barring of course a serious regression bug. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- 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
How to repair a BTRFS block?
Dear Btrfs developers, For some unknown reasons, my BTRFS filesystem is corrupted. dmesg prints |BTRFS critical (device sda2): corrupt leaf, slot offset bad: block=43231330304,root=1, slot=47| (more than 1000x in the dmesg trace). btrfs check --repair fails with: read block failed check_tree_block incorrect offset 12725 2298746482 items overlap, can't fix cmds_check.c:2918: fix_item_offset: Assertion 'ret' failed How to list the files in block #43231330304 affected by the corruption? How to repair block #43231330304? Best regards, --Martin -- 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
Re: how to clone a btrfs filesystem
Am Samstag, 18. April 2015, 01:08:44 schrieb Christoph Anton Mitterer: Hey. Hi Christoph, I've seen that this has been asked some times before, and there are stackoverflow/etc. questions on that, but none with a really good answer. How can I best copy one btrfs filesystem (with snapshots and subvolumes) into another, especially with keeping the CoW/reflink status of all files? And ideally incrementally upgrade it later (again with all snapshots/subvols, and again not loosing the shared blocks between these files). send/receive apparently also works for just one subvolume,... and documentation is quite sparse :-/ To make it short and simple: I am not aware of any out of the box solution for this use case. And I think that is just why you didn´t found any. I want to buy a new backup harddisk sometime in the future, and ideally transfer the contents of the current one with all subvolumes and snapshots, but I think except for some old backups that I have only there and I do not have the sources anymore, I will just start from scratch and let it collect its own snapshots. That said, I think it can be scripted. But I am not aware of anyone having done this. I may be missing something, so maybe someone on the list has a recommendation. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: incremental full file backups to smaller mediums possible?
Am Samstag, 18. April 2015, 01:03:23 schrieb Christoph Anton Mitterer: On Thu, 2015-04-09 at 16:33 +, Hugo Mills wrote: btrfs sub find-new might be more helpful to you here. That will give you the list of changed files; then just feed that list to your existing bin-packing algorithm for working out what goes on which disks, and you're done. hmm that sounds interesting, but a) it lacks much documentation (how does that with the generations work? when is there a new generation? what, if the generation overflows?) I have no idea about when there is a new generation. I think it depends on the commit intervall. You can see the current generation with: merkaba:~ btrfs subvol show / | grep Generation Generation (Gen): 468143 b) it seems to only show me new files, but not files that have been moved, or removed, or when properties have changed. It should show renamed or moved files. But yeah, if it does, at least not in a way that shows that a rename or move operation took place. c) it seems to work only for one subvolume? Its per subvolume, I think. Thats why it is under btrfs subvolume Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
