How to recover using a full backup?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

How to recover using a full backup?

Volker Wysk
Hi!

I'm making full backups of my system, on an external hard disc. It's a
combination of incremental and differential backup (accoding to the definitions
on wikipedia). So there isn't included everything in each backup, but only the
difference to the last time (or one of the last times, to be correct). This
works well.

The backup contains almost everything, excluding only things like /tmp,
/home/.../tmp, /dev, /proc and a few others.

I've needed to resort to parts of the backup in various occasions, but I never
needed to restore the full system. Now, imagine something really bad is
happening. Such as the hard disc needs to be replaced, because it is defect.

Or a failure of some large upgrade or do-release-upgrade operation, leaving the
system in an broken state beyond repair. Such that a full restoration becomes
necessary. This also applies to the (not so bad) case when one just wants to
switch to a bigger disk.

Then, I would need to boot from a different drive, such as an USB stick, make a
new file system on the (new or old) disc and restore the full backup in there.

I wonder how this is done. Just unpacking the backup doesn't do it. According
to what I know, there should some "update-initramfs -u" and "grub-install"
commands be necessary. But first some "mount --bind" commands are necessary,
such that the configuration files are in the right places. And I don't know if
there is more needing to be considered.

So, how is this done?

Thanks,
Volker


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to recover using a full backup?

Ian Bruntlett
Hi Volker,

It all depends on which backup/restore program you are using.

Personally, I create tar files of important things (personal data) only.

HTH,

Ian

--
-- ACCU - Professionalism in programming - http://www.accu.org
-- My writing - https://sites.google.com/site/ianbruntlett/


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to recover using a full backup?

Colin Watson
In reply to this post by Volker Wysk
On Mon, Sep 03, 2018 at 12:31:00AM +0200, Volker Wysk wrote:
> I'm making full backups of my system, on an external hard disc. It's a
> combination of incremental and differential backup (accoding to the definitions
> on wikipedia). So there isn't included everything in each backup, but only the
> difference to the last time (or one of the last times, to be correct). This
> works well.
>
> The backup contains almost everything, excluding only things like /tmp,
> /home/.../tmp, /dev, /proc and a few others.

This is the kind of backup strategy I prefer too: it allows both picking
out individual files for spot-restores and restoring the entire system.

One caution: for full-system backups, you need to make sure that your
handling of various bits of file metadata is exactly faithful, and there
are some gotchas there.  You should check these things, both that the
backup preserves them, *and* that your restore strategy preserves them:

 * symlinks are preserved as symlinks rather than copying the contents
 * hardlinks are preserved (i.e. if two files share the same inode, then
   this is true in the backup as well)
 * extended attributes are preserved
 * modification times are preserved
 * numeric user and group IDs are used throughout, rather than assuming
   that user and group names can be looked up in matching passwd and
   group databases which probably won't be available when you're doing a
   full-system restore (I got this wrong once and it was a right pain to
   fix everything up manually)
 * sparse files are handled efficiently (this isn't vital, but if you
   have any sparse files on your system then you can end up with the
   restored system taking up a lot more disk space than it used to
   otherwise)

If you aren't careful about these things, you can end up with a restored
system that superficially and mostly works but that has some oddities
you'll run into over time.  For instance, failing to preserve extended
attributes will result in some programs not running with the correct
privileges, so e.g. mtr and gnome-keyring won't work properly.

You may want to make a backup of the disk's partition table structure,
e.g. using sfdisk.  You can just leave this in a file that gets backed
up along with the rest of the system.  Check that you have nothing in
other partitions that you can't reconstruct.

> Then, I would need to boot from a different drive, such as an USB stick, make a
> new file system on the (new or old) disc and restore the full backup in there.
>
> I wonder how this is done. Just unpacking the backup doesn't do it. According
> to what I know, there should some "update-initramfs -u" and "grub-install"
> commands be necessary. But first some "mount --bind" commands are necessary,
> such that the configuration files are in the right places. And I don't know if
> there is more needing to be considered.

My usual strategy is to retain a copy of the UUID of the old file
system, which doesn't involve any extra backup work; you'll have it
somewhere in there, e.g. in /boot/grub/grub.cfg.  Then after restoring
files I grep for that in /etc and update any matching files to refer to
the UUID of the newly-created file system.  (Note that this is not
necessary in the case where you're simply reverting to an earlier state
after a catastrophic sysadmin failure, since in that case you don't need
to create a new file system.)

After that, you've got it all - the procedure goes roughly like this:

  mount --rbind /dev /mnt/dev
  mount --rbind /proc /mnt/proc
  mount --rbind /sys /mnt/sys
  chroot /mnt
  update-initramfs -u
  grub-install [possibly with suitable arguments]
  update-grub

Then unmount everything and reboot.  By definition you have recovery
media at this point, so even if you do need to iterate a little bit it
won't be too bad.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to recover using a full backup?

Volker Wysk
Am Montag, 3. September 2018, 10:33:20 CEST schrieb Colin Watson:

> On Mon, Sep 03, 2018 at 12:31:00AM +0200, Volker Wysk wrote:
> > I'm making full backups of my system, on an external hard disc. It's a
> > combination of incremental and differential backup (accoding to the definitions
> > on wikipedia). So there isn't included everything in each backup, but only the
> > difference to the last time (or one of the last times, to be correct). This
> > works well.
> >
> > The backup contains almost everything, excluding only things like /tmp,
> > /home/.../tmp, /dev, /proc and a few others.
>
> This is the kind of backup strategy I prefer too: it allows both picking
> out individual files for spot-restores and restoring the entire system.
 
> One caution: for full-system backups, you need to make sure that your
> handling of various bits of file metadata is exactly faithful, and there
> are some gotchas there.  You should check these things, both that the
> backup preserves them, *and* that your restore strategy preserves them:

I'm using Dar, see:
http://dar.linux.free.fr/

>  * symlinks are preserved as symlinks rather than copying the contents
yes.

>  * hardlinks are preserved (i.e. if two files share the same inode, then
>    this is true in the backup as well)
yes.

>  * extended attributes are preserved
yes.

>  * modification times are preserved
probably.

>  * numeric user and group IDs are used throughout, rather than assuming
>    that user and group names can be looked up in matching passwd and
>    group databases which probably won't be available when you're doing a
>    full-system restore (I got this wrong once and it was a right pain to
>    fix everything up manually)
not sure.

>  * sparse files are handled efficiently (this isn't vital, but if you
>    have any sparse files on your system then you can end up with the
>    restored system taking up a lot more disk space than it used to
>    otherwise)
again, not sure.

I've asked Denis Corbin, the author of dar, about those requirements. (Waiting for answer) They are probably all met. Dar is not bad at all.


> You may want to make a backup of the disk's partition table structure,
> e.g. using sfdisk.  You can just leave this in a file that gets backed
> up along with the rest of the system.  Check that you have nothing in
> other partitions that you can't reconstruct.

What would one do with the disk's partition table structure..?

 

> > Then, I would need to boot from a different drive, such as an USB stick, make a
> > new file system on the (new or old) disc and restore the full backup in there.
> >
> > I wonder how this is done. Just unpacking the backup doesn't do it. According
> > to what I know, there should some "update-initramfs -u" and "grub-install"
> > commands be necessary. But first some "mount --bind" commands are necessary,
> > such that the configuration files are in the right places. And I don't know if
> > there is more needing to be considered.
>
> My usual strategy is to retain a copy of the UUID of the old file
> system, which doesn't involve any extra backup work; you'll have it
> somewhere in there, e.g. in /boot/grub/grub.cfg.  Then after restoring
> files I grep for that in /etc and update any matching files to refer to
> the UUID of the newly-created file system.  (Note that this is not
> necessary in the case where you're simply reverting to an earlier state
> after a catastrophic sysadmin failure, since in that case you don't need
> to create a new file system.)
>
> After that, you've got it all - the procedure goes roughly like this:
>
>   mount --rbind /dev /mnt/dev
>   mount --rbind /proc /mnt/proc
>   mount --rbind /sys /mnt/sys
>   chroot /mnt
>   update-initramfs -u
>   grub-install [possibly with suitable arguments]
>   update-grub

This should be "grub-install /dev/sda".

> Then unmount everything and reboot.  By definition you have recovery
> media at this point, so even if you do need to iterate a little bit it
> won't be too bad.

Thanks for your competent and elaborate answer.  :-)  Even if I don't fully understand yet.


Bye
Volker


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to recover using a full backup?

Volker Wysk
In reply to this post by Ian Bruntlett
Am Montag, 3. September 2018, 10:28:14 CEST schrieb Ian Bruntlett:
> Hi Volker,
>
> It all depends on which backup/restore program you are using.
>
> Personally, I create tar files of important things (personal data) only.

I'm using dar, and it seems to be just right, even when you want to restore the whole system. See the message of Colin Watson and my answer.

Bye
Volker

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to recover using a full backup?

Colin Watson
In reply to this post by Volker Wysk
On Mon, Sep 03, 2018 at 05:39:22PM +0200, Volker Wysk wrote:
> Am Montag, 3. September 2018, 10:33:20 CEST schrieb Colin Watson:
> > You may want to make a backup of the disk's partition table structure,
> > e.g. using sfdisk.  You can just leave this in a file that gets backed
> > up along with the rest of the system.  Check that you have nothing in
> > other partitions that you can't reconstruct.
>
> What would one do with the disk's partition table structure..?

If you need to restore to a new disk, you're going to want to put some
kind of partition table on it first.  It may not be identical to the old
one, especially if the disk is a different size, but you'll probably at
least want the old table as a reference unless it's extremely simple and
memorable.

I normally work on the assumption that a restore may be happening in a
somewhat stressful situation (failed hardware and you need to get the
machine working again), and so it's a good idea to minimise the amount
of thinking I need to do.

> >   grub-install [possibly with suitable arguments]
>
> This should be "grub-install /dev/sda".

Yes, though bear in mind that if you've booted from a USB stick then
it's not entirely impossible that the USB stick will be /dev/sda.  I
always check first in that sort of situation, e.g. using "udevadm info".

--
Colin Watson                                       [[hidden email]]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to recover using a full backup?

Volker Wysk
Am Montag, 3. September 2018, 17:01:24 CEST schrieb Colin Watson:

> On Mon, Sep 03, 2018 at 05:39:22PM +0200, Volker Wysk wrote:
> > Am Montag, 3. September 2018, 10:33:20 CEST schrieb Colin Watson:
> > > You may want to make a backup of the disk's partition table structure,
> > > e.g. using sfdisk.  You can just leave this in a file that gets backed
> > > up along with the rest of the system.  Check that you have nothing in
> > > other partitions that you can't reconstruct.
> >
> > What would one do with the disk's partition table structure..?
>
> If you need to restore to a new disk, you're going to want to put some
> kind of partition table on it first.  It may not be identical to the old
> one, especially if the disk is a different size, but you'll probably at
> least want the old table as a reference unless it's extremely simple and
> memorable.

Okay. I use fdisk for my partitioning needs. "fdisk -l /dev/..." for instance.
 
> I normally work on the assumption that a restore may be happening in a
> somewhat stressful situation (failed hardware and you need to get the
> machine working again), and so it's a good idea to minimise the amount
> of thinking I need to do.

That's a sensible assumption. :-)

> > >   grub-install [possibly with suitable arguments]
> >
> > This should be "grub-install /dev/sda".
>
> Yes, though bear in mind that if you've booted from a USB stick then
> it's not entirely impossible that the USB stick will be /dev/sda.  I
> always check first in that sort of situation, e.g. using "udevadm info".

"lsblk" can also be used...


Cheers
Volker


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to recover using a full backup?

Volker Wysk
In reply to this post by Colin Watson
Am Montag, 3. September 2018, 10:33:20 CEST schrieb Colin Watson:
> My usual strategy is to retain a copy of the UUID of the old file
> system, which doesn't involve any extra backup work; you'll have it
> somewhere in there, e.g. in /boot/grub/grub.cfg.  

The only places seem to be /etc/fstab and /boot/grub/grub.cfg.

> Then after restoring
> files I grep for that in /etc and update any matching files to refer to
> the UUID of the newly-created file system.  (Note that this is not
> necessary in the case where you're simply reverting to an earlier state
> after a catastrophic sysadmin failure, since in that case you don't need
> to create a new file system.)

grub.cfg has this at the top:

-----snip-----
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
-----snip-----

So it should not be updated manually. Instead some grub-mkconfig invocation should be done... Or is it done by grub-install?

 
> After that, you've got it all - the procedure goes roughly like this:
>
>   mount --rbind /dev /mnt/dev
>   mount --rbind /proc /mnt/proc
>   mount --rbind /sys /mnt/sys
>   chroot /mnt
>   update-initramfs -u
>   grub-install [possibly with suitable arguments]
>   update-grub

Okay. That's what I've been thinking about.

> Then unmount everything and reboot.  By definition you have recovery
> media at this point, so even if you do need to iterate a little bit it
> won't be too bad.

I don't get this. (Why unmount manually? Recovery media? iterate?)


Thanks!
Volker

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to recover using a full backup?

Colin Watson
On Mon, Sep 03, 2018 at 10:16:53PM +0200, Volker Wysk wrote:

> Am Montag, 3. September 2018, 10:33:20 CEST schrieb Colin Watson:
> > Then after restoring
> > files I grep for that in /etc and update any matching files to refer to
> > the UUID of the newly-created file system.  (Note that this is not
> > necessary in the case where you're simply reverting to an earlier state
> > after a catastrophic sysadmin failure, since in that case you don't need
> > to create a new file system.)
>
> grub.cfg has this at the top:
>
> -----snip-----
> #
> # DO NOT EDIT THIS FILE
> #
> # It is automatically generated by grub-mkconfig using templates
> # from /etc/grub.d and settings from /etc/default/grub
> #
> -----snip-----
>
> So it should not be updated manually. Instead some grub-mkconfig invocation should be done... Or is it done by grub-install?

I mentioned update-grub in my instructions, which should take care of it
(although when doing a full-system restore I'd check the results to make
sure).

> > Then unmount everything and reboot.  By definition you have recovery
> > media at this point, so even if you do need to iterate a little bit it
> > won't be too bad.
>
> I don't get this. (Why unmount manually? Recovery media? iterate?)

Unmount manually: probably just my habit, but I prefer to do this to
make sure everything's been written to disk.

Recovery media: by definition you're running this from a live image,
right?  That means that if you find you missed something subtle then you
can boot from the same live image again to fix things up.

Iterate: jargon, sorry.  "Try again with minor adjustments".

--
Colin Watson                                       [[hidden email]]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to recover using a full backup?

Volker Wysk
In reply to this post by Colin Watson
Hi

Am Montag, 3. September 2018, 10:33:20 CEST schrieb Colin Watson:

> One caution: for full-system backups, you need to make sure that your
> handling of various bits of file metadata is exactly faithful, and there
> are some gotchas there.  You should check these things, both that the
> backup preserves them, *and* that your restore strategy preserves them:
>
>  * symlinks are preserved as symlinks rather than copying the contents
>  * hardlinks are preserved (i.e. if two files share the same inode, then
>    this is true in the backup as well)
>  * extended attributes are preserved
>  * modification times are preserved
>  * numeric user and group IDs are used throughout, rather than assuming
>    that user and group names can be looked up in matching passwd and
>    group databases which probably won't be available when you're doing a
>    full-system restore (I got this wrong once and it was a right pain to
>    fix everything up manually)
>  * sparse files are handled efficiently (this isn't vital, but if you
>    have any sparse files on your system then you can end up with the
>    restored system taking up a lot more disk space than it used to
>    otherwise)

Note:  Dar meets all of these requirements. See https://sourceforge.net/p/dar/mailman/message/36407058/ for details.

Volker


--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|

Re: How to recover using a full backup?

Colin Watson
On Thu, Sep 06, 2018 at 02:42:12AM +0200, Volker Wysk wrote:
> Note:  Dar meets all of these requirements. See
> https://sourceforge.net/p/dar/mailman/message/36407058/ for details.

Sounds appropriate then.  Thanks for following up.

--
Colin Watson                                       [[hidden email]]

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users