RE: SLES 11 SP4: can't mount btrfs
>> But it could simply be that you have forgotten to refresh the >> 'initramfs' with 'mkinitrd' after modifying the '/etc/fstab'. > I finally managed it. I'm pretty sure having changed > /boot/grub/menu.lst, but somehow changes got lost/weren't > saved ? So the next thing to check would indeed have been that the GRUB2 script had been updated, which you can do with 'grub2-mkconfig'. Also double check that in '/etc/sysconfig/bootloader' there is a line 'LOADER_TYPE="grub"' instead of "none". The system config tools will update the 'initramfs' and the 'menu.lst' automatically only if you make system config changes only using them, but you changed the UUID of '/' "manually", and this perhaps put the GRUB2 config and the system state out of sync. > After entering the new UUID from my Btrfs partition system > boots. Alternatively you could have used 'btrfstune -U ... ...' to change the UUID of the newly created '/' volume to the old one. -- 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: SLES 11 SP4: can't mount btrfs
> -Original Message- > From: Andrei Borzenkov [mailto:arvidj...@gmail.com] > Sent: Thursday, October 26, 2017 6:51 PM > To: Lentes, Bernd ; Btrfs ML > > Subject: Re: SLES 11 SP4: can't mount btrfs > > root device information is stored in initrd, you need to rebuild it. > Just run mkinitrd after you boot system. I can't confirm that. Just moved an old SLES 10 SP4 from one host to the other. Just changed menu.lst (GRUB) and fstab, system is booting. No need to rebuild initrd. But maybe just because it's an old system. Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 -- 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: SLES 11 SP4: can't mount btrfs
26.10.2017 15:18, Lentes, Bernd пишет: > >> -Original Message- >> From: linux-btrfs-ow...@vger.kernel.org >> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Lentes, Bernd >> Sent: Tuesday, October 24, 2017 6:44 PM >> To: Btrfs ML >> Subject: RE: SLES 11 SP4: can't mount btrfs >> >> >>> >>> A short-term alternative, if you've got a full backup of what SLES >>> mounts as /, is to run a regular install, boot the system, and then >>> extract the backup on top of /. It's not perfect, but it should work >>> well enough. >> >> That's what I'm currently trying. I will keep you informed. >> > > I was able to restore the root fs. I formatted the / partition with Btrfs > again and could restore the files from a backup. > Everything seems to be there, I can mount the Btrfs manually. > But booting does not work. My Btrfs resides on a logical volume. I changed > /boot/grub/menu.lst and /etc/fstab to point to the lv. Before it was > pointing to a UUID. > But booting my SLES complains that it does not find the root fs. screenshot: > https://hmgubox.helmholtz-muenchen.de/f/2d6b374e8a8b40569d4f/?dl=1 > > I can manually mount from the booted SLES. So everything (Btrfs, lvm) seems > to be available. I added in menu.lst and fstab the path to the device node > (/dev/vg1/lv_root), which works on other systems the same way, the only > difference is there I have ext3. > But SLES finds from where I don't know a UUID (see screenshot). This UUID is > commented out in fstab and replaced by /dev/vg1/lv_root. Using > /dev/vg1/lv_root I can manually mount my Btrfs without any problem. > > Where does my SLES find that UUID ? It is not available unter > /dev/disk/by-uuid. Can I change that value ? > root device information is stored in initrd, you need to rebuild it. Just run mkinitrd after you boot system. -- 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: SLES 11 SP4: can't mount btrfs
> -Original Message- > From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Peter Grandi > Sent: Thursday, October 26, 2017 2:55 PM > To: Linux fs Btrfs > Subject: RE: SLES 11 SP4: can't mount btrfs > > > I formatted the / partition with Btrfs again and could restore > > the files from a backup. Everything seems to be there, I can > > mount the Btrfs manually. [ ... ] But SLES finds from where I > > don't know a UUID (see screenshot). This UUID is commented out > > in fstab and replaced by /dev/vg1/lv_root. Using > > /dev/vg1/lv_root I can manually mount my Btrfs without any > > problem. Where does my SLES find that UUID ? > > This sounds like a SLES issue, rather than a Btrfs one. > > But it could simply be that you have forgotten to refresh the > 'initramfs' with 'mkinitrd' after modifying the '/etc/fstab'. I finally managed it. I'm pretty sure having changed /boot/grub/menu.lst, but somehow changes got lost/weren't saved ? After entering the new UUID from my Btrfs partition system boots. Sorry for PM Peter. Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 -- 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: SLES 11 SP4: can't mount btrfs
> I formatted the / partition with Btrfs again and could restore > the files from a backup. Everything seems to be there, I can > mount the Btrfs manually. [ ... ] But SLES finds from where I > don't know a UUID (see screenshot). This UUID is commented out > in fstab and replaced by /dev/vg1/lv_root. Using > /dev/vg1/lv_root I can manually mount my Btrfs without any > problem. Where does my SLES find that UUID ? This sounds like a SLES issue, rather than a Btrfs one. But it could simply be that you have forgotten to refresh the 'initramfs' with 'mkinitrd' after modifying the '/etc/fstab'. -- 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: SLES 11 SP4: can't mount btrfs
> -Original Message- > From: linux-btrfs-ow...@vger.kernel.org > [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Lentes, Bernd > Sent: Tuesday, October 24, 2017 6:44 PM > To: Btrfs ML > Subject: RE: SLES 11 SP4: can't mount btrfs > > > > > > A short-term alternative, if you've got a full backup of what SLES > > mounts as /, is to run a regular install, boot the system, and then > > extract the backup on top of /. It's not perfect, but it should work > > well enough. > > That's what I'm currently trying. I will keep you informed. > I was able to restore the root fs. I formatted the / partition with Btrfs again and could restore the files from a backup. Everything seems to be there, I can mount the Btrfs manually. But booting does not work. My Btrfs resides on a logical volume. I changed /boot/grub/menu.lst and /etc/fstab to point to the lv. Before it was pointing to a UUID. But booting my SLES complains that it does not find the root fs. screenshot: https://hmgubox.helmholtz-muenchen.de/f/2d6b374e8a8b40569d4f/?dl=1 I can manually mount from the booted SLES. So everything (Btrfs, lvm) seems to be available. I added in menu.lst and fstab the path to the device node (/dev/vg1/lv_root), which works on other systems the same way, the only difference is there I have ext3. But SLES finds from where I don't know a UUID (see screenshot). This UUID is commented out in fstab and replaced by /dev/vg1/lv_root. Using /dev/vg1/lv_root I can manually mount my Btrfs without any problem. Where does my SLES find that UUID ? It is not available unter /dev/disk/by-uuid. Can I change that value ? Thanks for any help. Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 -- 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: SLES 11 SP4: can't mount btrfs
> -Original Message- > From: linux-btrfs-ow...@vger.kernel.org > [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Austin S. > Hemmelgarn > Sent: Tuesday, October 24, 2017 4:05 PM > To: Lentes, Bernd ; Btrfs ML > > Subject: Re: SLES 11 SP4: can't mount btrfs > > A short-term alternative, if you've got a full backup of what SLES > mounts as /, is to run a regular install, boot the system, and then > extract the backup on top of /. It's not perfect, but it should work > well enough. That's what I'm currently trying. I will keep you informed. > As mentioned, I'm working on a script to handle this for tools like > Amanda and Bareos. I plan to send a message out on the list when that's > sufficiently working that I think it's safely usable, I can make sure > you're on CC for that message as well if you like. I hoped to have > something later this week, but things are busier than expected at work > this week, so it might be a while. Please put me on cc. That would be great. Thanks. Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 -- 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: SLES 11 SP4: can't mount btrfs
On 2017-10-24 10:12, Andrei Borzenkov wrote: On Tue, Oct 24, 2017 at 2:53 PM, Austin S. Hemmelgarn wrote: SLES (and OpenSUSE in general) does do something special though, they use subvolumes and qgroups to replicate multiple independent partitions (which is a serious pain in the arse), and they have snapshotting with snapper by default as well. On OpenSUSE at least you can dispense with all that crap by telling the installer to not enable snapshot support, not sure about SLES though. SUSE is using so many subvolumes because a) it wants to use snapshot of operating system to enable rollback b) data that needs to be part of snapshot includes RPM database c) RPM database is located on /var So they were forced to make /var part of root subvolume and explicitly exclude everything below /var by making it separate subvolumes. Fortunately it is going to change now with both RH and SUSE moving RPM database under /usr. Which leaves you basically with / and /var as default subvolumes. And /tmp, and /opt, and /usr/local, etc. With /var as one subvolume, I still count at least 8. That said, the issue I have with it is not as much the number, as the choice of layout (the whole /@ crap is ridiculous), and the fact that qgroups are enabled by default and not very well documented anywhere that I could find (seriously, this needs to be better documented, it took me an hour despite my background with BTRFS and as a system administrator to figure out why I couldn't fill the disk completely anywhere to wipe free space with zeroes so I could compact the disk image for the VM I was using). -- 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: SLES 11 SP4: can't mount btrfs
On Tue, Oct 24, 2017 at 2:53 PM, Austin S. Hemmelgarn wrote: > > SLES (and OpenSUSE in general) does do something special though, they use > subvolumes and qgroups to replicate multiple independent partitions (which > is a serious pain in the arse), and they have snapshotting with snapper by > default as well. On OpenSUSE at least you can dispense with all that crap > by telling the installer to not enable snapshot support, not sure about SLES > though. SUSE is using so many subvolumes because a) it wants to use snapshot of operating system to enable rollback b) data that needs to be part of snapshot includes RPM database c) RPM database is located on /var So they were forced to make /var part of root subvolume and explicitly exclude everything below /var by making it separate subvolumes. Fortunately it is going to change now with both RH and SUSE moving RPM database under /usr. Which leaves you basically with / and /var as default subvolumes. -- 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: SLES 11 SP4: can't mount btrfs
On 2017-10-24 09:28, Lentes, Bernd wrote: -Original Message- From: Austin S. Hemmelgarn [mailto:ahferro...@gmail.com] Sent: Tuesday, October 24, 2017 1:53 PM To: Adam Borowski ; Lentes, Bernd Cc: Btrfs ML Subject: Re: SLES 11 SP4: can't mount btrfs I think partimage _might_ have BTRFS support by now, and if so, that's likely to be the best you can get for quite some time. Unfortunately not: http://www.partimage.org/Supported-Filesystems/ It depends on what you use subvolumes for. And this is the important part. If you're just using them to segregate workloads (like I do), or exclude things from snapshots (like I used to do when I was using snapshots for backups), then any old backup program is fine as long as you know enough to replicate the subvolume layout when extracting (if you need the same layout that is). I'm actually working on a script to automate this for file-level backups (stuff like Amanda, Bareos, and borgbackup), but I don't have anything ready to share yet.> There seems to be no backup solution which supports BTRFS in a way that I can just restore the complete partition with all subvolumes, snapshots ? That's bad. A fs can also get corrupt in certain circumstances. I'd like to have a solution which offers me the possibility to restore a root partition in a reasonable time (some hours maximum), completely. Not doing many stuff before/afterwards. It seems that's not possible withBTRFS. A short-term alternative, if you've got a full backup of what SLES mounts as /, is to run a regular install, boot the system, and then extract the backup on top of /. It's not perfect, but it should work well enough. As mentioned, I'm working on a script to handle this for tools like Amanda and Bareos. I plan to send a message out on the list when that's sufficiently working that I think it's safely usable, I can make sure you're on CC for that message as well if you like. I hoped to have something later this week, but things are busier than expected at work this week, so it might be a while. And Btrfs check is still limited in what it can do. -- 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: SLES 11 SP4: can't mount btrfs
> -Original Message- > From: Austin S. Hemmelgarn [mailto:ahferro...@gmail.com] > Sent: Tuesday, October 24, 2017 1:53 PM > To: Adam Borowski ; Lentes, Bernd > > Cc: Btrfs ML > Subject: Re: SLES 11 SP4: can't mount btrfs > > I think partimage _might_ have BTRFS support by now, and if so, that's > likely to be the best you can get for quite some time. Unfortunately not: http://www.partimage.org/Supported-Filesystems/ > > It depends on what you use subvolumes for. > And this is the important part. If you're just using them to segregate > workloads (like I do), or exclude things from snapshots (like I used to do > when I was using snapshots for backups), then any old backup program is > fine as long as you know enough to replicate the subvolume layout when > extracting (if you need the same layout that is). I'm actually working on > a > script to automate this for file-level backups (stuff like Amanda, Bareos, > and borgbackup), but I don't have anything ready to share yet.> There seems to be no backup solution which supports BTRFS in a way that I can just restore the complete partition with all subvolumes, snapshots ? That's bad. A fs can also get corrupt in certain circumstances. I'd like to have a solution which offers me the possibility to restore a root partition in a reasonable time (some hours maximum), completely. Not doing many stuff before/afterwards. It seems that's not possible withBTRFS. And Btrfs check is still limited in what it can do. Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 -- 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: SLES 11 SP4: can't mount btrfs
On 2017-10-21 14:07, Adam Borowski wrote: On Sat, Oct 21, 2017 at 01:46:06PM +0200, Lentes, Bernd wrote: - Am 21. Okt 2017 um 4:31 schrieb Duncan 1i5t5.dun...@cox.net: Lentes, Bernd posted on Fri, 20 Oct 2017 20:40:15 +0200 as excerpted: Is it generally possible to restore a btrfs partition from a tape backup ? I'm just starting, and I'm asking myself. What is about the subvolumes ? This information isn't stored in files, but in the fs ? This is not on a file-based backup on a tape. Yes it's possible to restore a btrfs partition from tape backup, /if/ you backed up the partition itself, not just the files on top of it. Which is usually a quite bad idea: unless you shut down (or remount ro) the filesystem in question, the data _will_ be corrupted, and in the case of btrfs, this kind of corruption tends to be fatal. You also back up all the unused space (trim greatly recommended), and the backup process takes ages as it needs to read everything. An efficient block-level backup of btrfs _would_ be possible as it can nicely enumerate blocks touched since generation X, but AFAIK no one wrote such a program yet. It'd be also corruption free if done in two passes: first a racey copy, fsfreeze(), copy of just newest updates. I think partimage _might_ have BTRFS support by now, and if so, that's likely to be the best you can get for quite some time. Otherwise, as you deduce, you get the files, but not the snapshot history or relationship, nor the subvolumes, which will look to normal file-level backup software (that is, backup software not designed with btrfs- specifics like subvolumes, which if it did, would likely use btrfs send/ receive at least optionally) like normal directories. If the backup software does incrementals well, this is not as bad as it sounds. While rsync takes half an hour just to stat() a typical small piece spinning rust (obviously depending on # of files), that's still in the acceptable range. That backup software can be then be told to back every snapshot in turn. You still lose reflinks between unrelated subvolumes but those tend to be quite rare -- and you can re-dedupe. i apprehend that i have just a file based backup. We use EMC Networker (version 8.1 or 8.2), and from what i read in the net i think it does not support BTRFS. So i have to reinstall, which is maybe not the worst, because i'm thinking about using SLES 11 SP3. What i know now is that i can't rely on our EMC backup. What would you propose to backup a complete btrfs partition (https://btrfs.wiki.kernel.org/index.php/Incremental_Backup) ? We have a NAS with propable enough space, and the servers aren't used heavily over night. So using one of the mentioned tools in a cronjob over night is possible. Which tool do you recommend ? It depends on what you use subvolumes for. And this is the important part. If you're just using them to segregate workloads (like I do), or exclude things from snapshots (like I used to do when I was using snapshots for backups), then any old backup program is fine as long as you know enough to replicate the subvolume layout when extracting (if you need the same layout that is). I'm actually working on a script to automate this for file-level backups (stuff like Amanda, Bareos, and borgbackup), but I don't have anything ready to share yet.> While a simple file-base backup may be inadequate for the general case, for most actual uses it works well or at least well enough. Only if you're doing something special, bothering with the complexity might be worth it. SLES (and OpenSUSE in general) does do something special though, they use subvolumes and qgroups to replicate multiple independent partitions (which is a serious pain in the arse), and they have snapshotting with snapper by default as well. On OpenSUSE at least you can dispense with all that crap by telling the installer to not enable snapshot support, not sure about SLES though. -- 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: SLES 11 SP4: can't mount btrfs
- Am 21. Okt 2017 um 20:07 schrieb Adam Borowski kilob...@angband.pl: >> > Yes it's possible to restore a btrfs partition from tape backup, /if/ you >> > backed up the partition itself, not just the files on top of it. > > Which is usually a quite bad idea: unless you shut down (or remount ro) the > filesystem in question, the data _will_ be corrupted, and in the case of > btrfs, this kind of corruption tends to be fatal. You also back up all the > unused space (trim greatly recommended), and the backup process takes ages > as it needs to read everything. > > An efficient block-level backup of btrfs _would_ be possible as it can > nicely enumerate blocks touched since generation X, but AFAIK no one wrote > such a program yet. It'd be also corruption free if done in two passes: > first a racey copy, fsfreeze(), copy of just newest updates. > >> > Otherwise, as you deduce, you get the files, but not the snapshot history >> > or relationship, nor the subvolumes, which will look to normal file-level >> > backup software (that is, backup software not designed with btrfs- >> > specifics like subvolumes, which if it did, would likely use btrfs send/ >> > receive at least optionally) like normal directories. > > If the backup software does incrementals well, this is not as bad as it > sounds. While rsync takes half an hour just to stat() a typical small piece > spinning rust (obviously depending on # of files), that's still in the > acceptable range. That backup software can be then be told to back every > snapshot in turn. You still lose reflinks between unrelated subvolumes but > those tend to be quite rare -- and you can re-dedupe. > >> i apprehend that i have just a file based backup. We use EMC Networker >> (version 8.1 or 8.2), and from what i read in the net i think it does not >> support BTRFS. So i have to reinstall, which is maybe not the worst, >> because i'm thinking about using SLES 11 SP3. >> >> What i know now is that i can't rely on our EMC backup. >> What would you propose to backup a complete btrfs partition >> (https://btrfs.wiki.kernel.org/index.php/Incremental_Backup) ? >> We have a NAS with propable enough space, and the servers aren't used >> heavily over night. So using one of the mentioned tools in a cronjob over >> night is possible. > >> Which tool do you recommend ? > > It depends on what you use subvolumes for. > > While a simple file-base backup may be inadequate for the general case, for > most actual uses it works well or at least well enough. Only if you're > doing something special, bothering with the complexity might be worth it. > > SLES creates a resonable number of subvolumes for e.g. /var/lib, /var/log, /tmp ... About 15 on a normal system. My setup would be a root-Partition on btrfs, with all the subvolumes. Here mount from a SLES 12 SP2 system: /dev/sda1 on / type btrfs (rw,ssd,space_cache,subvolid=1011,subvol=/@/.snapshots/355/snapshot) /dev/sda1 on /var/crash type btrfs (rw,relatime,ssd,space_cache,subvolid=264,subvol=/@/var/crash) /dev/sda1 on /var/log type btrfs (rw,relatime,ssd,space_cache,subvolid=268,subvol=/@/var/log) /dev/sda1 on /boot/grub2/x86_64-efi type btrfs (rw,relatime,ssd,space_cache,subvolid=259,subvol=/@/boot/grub2/x86_64-efi) /dev/sda1 on /var/tmp type btrfs (rw,relatime,ssd,space_cache,subvolid=271,subvol=/@/var/tmp) /dev/sda1 on /var/opt type btrfs (rw,relatime,ssd,space_cache,subvolid=269,subvol=/@/var/opt) /dev/sda1 on /usr/local type btrfs (rw,relatime,ssd,space_cache,subvolid=263,subvol=/@/usr/local) /dev/sda1 on /opt type btrfs (rw,relatime,ssd,space_cache,subvolid=260,subvol=/@/opt) /dev/sda1 on /var/lib/named type btrfs (rw,relatime,ssd,space_cache,subvolid=266,subvol=/@/var/lib/named) /dev/sda1 on /var/spool type btrfs (rw,relatime,ssd,space_cache,subvolid=270,subvol=/@/var/spool) /dev/sda1 on /var/lib/mailman type btrfs (rw,relatime,ssd,space_cache,subvolid=265,subvol=/@/var/lib/mailman) /dev/sda1 on /var/lib/pgsql type btrfs (rw,relatime,ssd,space_cache,subvolid=267,subvol=/@/var/lib/pgsql) /dev/sda1 on /tmp type btrfs (rw,relatime,ssd,space_cache,subvolid=262,subvol=/@/tmp) /dev/sda1 on /boot/grub2/i386-pc type btrfs (rw,relatime,ssd,space_cache,subvolid=258,subvol=/@/boot/grub2/i386-pc) /dev/sda1 on /srv type btrfs (rw,relatime,ssd,space_cache,subvolid=261,subvol=/@/srv) /dev/sda1 on /.snapshots type btrfs (rw,relatime,ssd,space_cache,subvolid=275,subvol=/@/.snapshots) My setup would be identical. It will be a node of a HA-cluster, no databases or s.th. else on the root-Partition. The resources are virtual machines on dedicated partitions. What would be the appropriate backup solution from https://btrfs.wiki.kernel.org/index.php/Incremental_Backup to be able to restore the complete btrfs partition including all subvolumes if i have a complete corruption like now ? Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764
Re: SLES 11 SP4: can't mount btrfs
On Sat, Oct 21, 2017 at 01:46:06PM +0200, Lentes, Bernd wrote: > - Am 21. Okt 2017 um 4:31 schrieb Duncan 1i5t5.dun...@cox.net: > > Lentes, Bernd posted on Fri, 20 Oct 2017 20:40:15 +0200 as excerpted: > > > >> Is it generally possible to restore a btrfs partition from a tape backup > >> ? > >> I'm just starting, and I'm asking myself. What is about the subvolumes ? > >> This information isn't stored in files, but in the fs ? This is not on a > >> file-based backup on a tape. > > > > Yes it's possible to restore a btrfs partition from tape backup, /if/ you > > backed up the partition itself, not just the files on top of it. Which is usually a quite bad idea: unless you shut down (or remount ro) the filesystem in question, the data _will_ be corrupted, and in the case of btrfs, this kind of corruption tends to be fatal. You also back up all the unused space (trim greatly recommended), and the backup process takes ages as it needs to read everything. An efficient block-level backup of btrfs _would_ be possible as it can nicely enumerate blocks touched since generation X, but AFAIK no one wrote such a program yet. It'd be also corruption free if done in two passes: first a racey copy, fsfreeze(), copy of just newest updates. > > Otherwise, as you deduce, you get the files, but not the snapshot history > > or relationship, nor the subvolumes, which will look to normal file-level > > backup software (that is, backup software not designed with btrfs- > > specifics like subvolumes, which if it did, would likely use btrfs send/ > > receive at least optionally) like normal directories. If the backup software does incrementals well, this is not as bad as it sounds. While rsync takes half an hour just to stat() a typical small piece spinning rust (obviously depending on # of files), that's still in the acceptable range. That backup software can be then be told to back every snapshot in turn. You still lose reflinks between unrelated subvolumes but those tend to be quite rare -- and you can re-dedupe. > i apprehend that i have just a file based backup. We use EMC Networker > (version 8.1 or 8.2), and from what i read in the net i think it does not > support BTRFS. So i have to reinstall, which is maybe not the worst, > because i'm thinking about using SLES 11 SP3. > > What i know now is that i can't rely on our EMC backup. > What would you propose to backup a complete btrfs partition > (https://btrfs.wiki.kernel.org/index.php/Incremental_Backup) ? > We have a NAS with propable enough space, and the servers aren't used > heavily over night. So using one of the mentioned tools in a cronjob over > night is possible. > Which tool do you recommend ? It depends on what you use subvolumes for. While a simple file-base backup may be inadequate for the general case, for most actual uses it works well or at least well enough. Only if you're doing something special, bothering with the complexity might be worth it. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. ⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift ⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters ⠈⠳⣄ relevant to duties], shall be punished by death by shooting. -- 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: SLES 11 SP4: can't mount btrfs
- Am 21. Okt 2017 um 4:31 schrieb Duncan 1i5t5.dun...@cox.net: > Lentes, Bernd posted on Fri, 20 Oct 2017 20:40:15 +0200 as excerpted: > >> Is it generally possible to restore a btrfs partition from a tape backup >> ? >> I'm just starting, and I'm asking myself. What is about the subvolumes ? >> This information isn't stored in files, but in the fs ? This is not on a >> file-based backup on a tape. > > Yes it's possible to restore a btrfs partition from tape backup, /if/ you > backed up the partition itself, not just the files on top of it. > > Otherwise, as you deduce, you get the files, but not the snapshot history > or relationship, nor the subvolumes, which will look to normal file-level > backup software (that is, backup software not designed with btrfs- > specifics like subvolumes, which if it did, would likely use btrfs send/ > receive at least optionally) like normal directories. > > -- Hi Duncan, i apprehend that i have just a file based backup. We use EMC Networker (version 8.1 or 8.2), and from what i read in the net i think it does not support BTRFS. So i have to reinstall, which is maybe not the worst, because i'm thinking about using SLES 11 SP3. What i know now is that i can't rely on our EMC backup. What would you propose to backup a complete btrfs partition (https://btrfs.wiki.kernel.org/index.php/Incremental_Backup) ? We have a NAS with propable enough space, and the servers aren't used heavily over night. So using one of the mentioned tools in a cronjob over night is possible. Which tool do you recommend ? Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 -- 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: SLES 11 SP4: can't mount btrfs
Lentes, Bernd posted on Fri, 20 Oct 2017 20:40:15 +0200 as excerpted: > Is it generally possible to restore a btrfs partition from a tape backup > ? > I'm just starting, and I'm asking myself. What is about the subvolumes ? > This information isn't stored in files, but in the fs ? This is not on a > file-based backup on a tape. Yes it's possible to restore a btrfs partition from tape backup, /if/ you backed up the partition itself, not just the files on top of it. Otherwise, as you deduce, you get the files, but not the snapshot history or relationship, nor the subvolumes, which will look to normal file-level backup software (that is, backup software not designed with btrfs- specifics like subvolumes, which if it did, would likely use btrfs send/ receive at least optionally) like normal directories. -- 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
RE: SLES 11 SP4: can't mount btrfs
> -Original Message- > From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs- > ow...@vger.kernel.org] On Behalf Of Lentes, Bernd > Sent: Friday, October 20, 2017 7:26 PM > To: Btrfs ML > Subject: RE: SLES 11 SP4: can't mount btrfs > > > > -Original Message- > > From: Andrei Borzenkov [mailto:arvidj...@gmail.com] > > Sent: Friday, October 20, 2017 6:09 AM > > To: Chris Murphy ; Lentes, Bernd > > > > Cc: Btrfs ML > > Subject: Re: SLES 11 SP4: can't mount btrfs > > > > Hi Andrei, > > thanks for that info. So I will not waste my time and restore from a > backup. > Or fresh installation with SLES 12 SP3 on my two cluster nodes, because > SLES > 11 SP4 is pretty old and support ends in beginning of 2019. > I also found the culprit for the disaster: the battery from the > write-cache > of the RAID-Controller was empty, I ordered a new one. > Is it generally possible to restore a btrfs partition from a tape backup ? I'm just starting, and I'm asking myself. What is about the subvolumes ? This information isn't stored in files, but in the fs ? This is not on a file-based backup on a tape. Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 -- 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: SLES 11 SP4: can't mount btrfs
> -Original Message- > From: Andrei Borzenkov [mailto:arvidj...@gmail.com] > Sent: Friday, October 20, 2017 6:09 AM > To: Chris Murphy ; Lentes, Bernd > > Cc: Btrfs ML > Subject: Re: SLES 11 SP4: can't mount btrfs > > 19.10.2017 23:04, Chris Murphy пишет: > > Btrfs > > is not just supported by SUSE, it's the default file system. > > > > It is default choice for root starting with SLES12, not in SLES11. But > yes, it > should still be supported. > > I do not hold my breath though. For all I can tell transid errors are > usually > fatal and if this is root, it may be easier and faster to just reinstall. Hi Andrei, thanks for that info. So I will not waste my time and restore from a backup. Or fresh installation with SLES 12 SP3 on my two cluster nodes, because SLES 11 SP4 is pretty old and support ends in beginning of 2019. I also found the culprit for the disaster: the battery from the write-cache of the RAID-Controller was empty, I ordered a new one. Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 -- 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: SLES 11 SP4: can't mount btrfs
Chris Murphy posted on Thu, 19 Oct 2017 21:04:26 +0100 as excerpted: > On Thu, Oct 19, 2017 at 6:43 PM, Lentes, Bernd > wrote: >> Hi, >> >> this is the continuation of a thread i started on a SLES forum >> (https://forums.suse.com/showthread.php?10109-lv-with-btrfs-corrupt- some-tips-please), >> but i think this is the more appropriate place. > > Maybe, but as this is SLES, you're effectively paying for support, and > it's actually better to open a support instance, in my opinion. This is what I'd recommend as well. That 3.0.x kernel is well out of the range this list tends to support, given that it's a forward-focused development list, not a stability- focused enterprise release support list. We generally go back a couple release series each in the mainline current and LTS release series, which means 4.13 and 4.12 on current, and 4.9 and 4.4 on LTS, but even 4.4 is getting pretty long in the tooth for this list, so it's fortunate that the coming 4.14 is going to be an LTS as well. While your knoppix had kernel 4.12.x which is list-reasonable for runtime, where the kernel code is primary, once something's going wrong and you can't mount, it's the userspace code that is responsible for check/rescue/ restore, and there your knoppix was a bit behind at 4.7.x. So your choices are to go really current and build a 4.13.x btrfs-progs to try, or to go with the SLES support you're paying for anyway, in which case you run what they say they'll support. Given that you were running that old code (plus backports we don't track as we're focused on mainline and forward development) already, and a 3.0 kernel really is scary- ancient in btrfs terms, they really are best positioned to support it, and given that you're presumably paying good money for that support already, you might as well use what you're paying for. -- 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
Re: SLES 11 SP4: can't mount btrfs
19.10.2017 23:04, Chris Murphy пишет: > Btrfs > is not just supported by SUSE, it's the default file system. > It is default choice for root starting with SLES12, not in SLES11. But yes, it should still be supported. I do not hold my breath though. For all I can tell transid errors are usually fatal and if this is root, it may be easier and faster to just reinstall. -- 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: SLES 11 SP4: can't mount btrfs
On Thu, Oct 19, 2017 at 6:43 PM, Lentes, Bernd wrote: > Hi, > > this is the continuation of a thread i started on a SLES forum > (https://forums.suse.com/showthread.php?10109-lv-with-btrfs-corrupt-some-tips-please), > but i think this is the more appropriate place. Maybe, but as this is SLES, you're effectively paying for support, and it's actually better to open a support instance, in my opinion. Btrfs is not just supported by SUSE, it's the default file system. > I booted the system now with knoppix 8.1, which has kernel 4.12.7 and > btrfs-progs 4.7.3-1. Is that ok ? Since it's SLES, you have to use whatever they recommend. I don't know Knoppix kernels, so I can't say with any certainty what's in 4.12.7, but 4.7.3 for btrfs-progs is rather old. There have been many improvements since that time, in particular with 'btrfs check' What I usually recommend is getting a current version of Fedora because it'll have very recent kernels, the gotcha being that to also get recent btrfs-progs you have to get a copy of Rawhide or like right now you could use Fedora 27 Beta which is decently safe and also has new kernel and progs, and in terms of Btrfs of block level stuff we care about, Fedora runs pretty much identical to to kernel.org code, so it's not like developers have to use secret decoder rings to know what the kernel version really means. https://getfedora.org/en/workstation/prerelease/ > I tried: > > mount /dev/vg1/lv_root /lv_root -o recovery,ro > and got: > mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg1-lv_root, >missing codepage or helper program, or other error > >In some cases useful info is found in syslog - try >dmesg | tail or so. > > > and got via dmesg: > [92518.955408] BTRFS info (device dm-0): disk space caching is enabled > [92518.990561] BTRFS error (device dm-0): parent transid verify failed on > 196314759168 wanted 793932 found 793496 > [92518.990911] BTRFS error (device dm-0): parent transid verify failed on > 196314759168 wanted 793932 found 793496 > [92518.990919] BTRFS error (device dm-0): failed to read block groups: -5 > [92519.070084] BTRFS error (device dm-0): open_ctree failed > > next step: > > root@Microknoppix:~# btrfs device scan > Scanning for Btrfs filesystems > root@Microknoppix:~# > > no result !?! Normal. Scan just tells btrfs to go look for devices, it doesn't return a result. > > Now i changed to https://btrfs.wiki.kernel.org/index.php/Restore: > > btrfs restore -smSvi /dev/vg1/lv_root > /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg-1/ |tee > /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg-1/recover.log > > I just started it. I get lines like: > offset is 61440 > offset is 98304 > offset is 4096 > offset is 143360 > offset is 8192 > offset is 184320 > > or > > Error searching > /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg-1/@/tmp/localhpsum/assets/doc/help/en > Error searching > /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg-1/@/tmp/localhpsum/assets/doc/help/ja/images/callouts > > What does that mean ? btrfs restore is pretty much just a brute force hammer for scraping data off a volume, pretty much it either works or doesn't work, there's not a lot of in between. You're probably better off doing both 'btrfs check' and 'btrfs check --mode=lowmem' without the --repair option, and report back what both results are. You can cancel the restore that's in progress is sounds like it's still doing something, but stuck in a loop maybe. I'm not sure if there are many restore fixes since btrfs-progs 4.7 though; you could check the changelog which is in the wiki. I think the way forward is to get a little more information for developers, and then maybe they'll be able to say whether --repair is safe to use or not in your situation. In any case, report back what you find out. It'd be useful. -- 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: SLES 11 SP4: can't mount btrfs
> -Original Message- > From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs- > ow...@vger.kernel.org] On Behalf Of Lentes, Bernd > Sent: Thursday, October 19, 2017 7:44 PM > To: Btrfs ML > Subject: SLES 11 SP4: can't mount btrfs > > Hi, > > this is the continuation of a thread i started on a SLES forum > (https://forums.suse.com/showthread.php?10109-lv-with-btrfs-corrupt- > some-tips-please), but i think this is the more appropriate place. > I have a SLES 11 SP4 with a btrfs on top of a logical volume i can't mount > anymore. The host was fenced in a two-node cluster, and the boot > procedure can't mount the lv, and i reside in simple shell (i assume the > one from initrd). > > I have a second nearly identical node, so i can give you some information: > > ha-idg-2:/etc/corosync # uname -a > Linux ha-idg-2 3.0.101-84-default #1 SMP Tue Oct 18 10:32:51 UTC 2016 > (15251d6) x86_64 x86_64 x86_64 GNU/Linux > > ha-idg-2:/etc/corosync # rpm -qa|grep -i btrfs > libbtrfs0-3.18.2-0.40.48 > btrfsmaintenance-0.1-3.1 > btrfsprogs-3.18.2-0.40.48 > > I try to follow the recommendations on > https://btrfs.wiki.kernel.org/index.php/Problem_FAQ. > > I booted the system now with knoppix 8.1, which has kernel 4.12.7 and > btrfs-progs 4.7.3-1. Is that ok ? > I tried: > > mount /dev/vg1/lv_root /lv_root -o recovery,ro and got: > mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg1- > lv_root, >missing codepage or helper program, or other error > >In some cases useful info is found in syslog - try >dmesg | tail or so. > > > and got via dmesg: > [92518.955408] BTRFS info (device dm-0): disk space caching is enabled > [92518.990561] BTRFS error (device dm-0): parent transid verify failed on > 196314759168 wanted 793932 found 793496 [92518.990911] BTRFS error > (device dm-0): parent transid verify failed on 196314759168 wanted > 793932 found 793496 [92518.990919] BTRFS error (device dm-0): failed to > read block groups: -5 [92519.070084] BTRFS error (device dm-0): > open_ctree failed > > next step: > > root@Microknoppix:~# btrfs device scan > Scanning for Btrfs filesystems > root@Microknoppix:~# > > no result !?! > > Now i changed to https://btrfs.wiki.kernel.org/index.php/Restore: > > btrfs restore -smSvi /dev/vg1/lv_root /mnt/idg- > 2/SysAdmin_AG_Wurst/recover/ha-idg-1/ |tee /mnt/idg- > 2/SysAdmin_AG_Wurst/recover/ha-idg-1/recover.log > > I just started it. I get lines like: > offset is 61440 > offset is 98304 > offset is 4096 > offset is 143360 > offset is 8192 > offset is 184320 > > or > > Error searching /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg- > 1/@/tmp/localhpsum/assets/doc/help/en > Error searching /mnt/idg-2/SysAdmin_AG_Wurst/recover/ha-idg- > 1/@/tmp/localhpsum/assets/doc/help/ja/images/callouts > > What does that mean ? > > > Bernd > The process does not continue, but it's still visible with ps. Also top does not show that this process is consuming resources. iotop does not show any activity on my lv. My logfile is unchanged for two hours. Does that mean that btrfs gave up or is it still struggling ? Bernd Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671 -- 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
