• Disaster recovery, how to automate as far as possible?

    From Chris Green@3:770/3 to All on Mon Aug 2 10:29:44 2021
    Recently (like last week-end) my Pi that runs local DNS died, I did an
    'apt update;apt upgrade', the /boot partition went read only and there
    was no kernel to boot from (the "7 short flashes" code from the LEDs
    was actually quite handy). Presumably the SD card failed in some way.

    I have good backups and was able to recover everything but it took
    quite a while (like Sunday morning) and, as a result I've been
    wondering if there's something I can do better.

    My existing backups are incremental backups taken daily of /etc and
    /home thus restoring the system meant that I got a new clean image,
    wrote my backups of /etc and /home to it and was back running again.
    However there were a few gotchas on the way, a few symbolic links from
    /etc had to be mended as well as installing some extra packages
    (fortunately I list packages I've added when I add them - very
    important!).


    So, what could I have done to make things quicker/easier?

    My incremental backups are automatic and run every night, when they're
    more than a month old the system weeds some of them out but I have
    monthly backups for some years back now. I'm not aiming to change this.

    However some sort of nightly 'image copy' would make what I had to do
    on Sunday much easier. It has to be automatic (i.e. run by anacron or
    cron) or it won't get done. This is a headless system so it has to
    be non-GUI too (with the advantage that as it's a "Lite" installation
    there's only about 1.5Gb of it to back up).

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it
    running quickly" backup I want, not the same as I have with the
    incremental backups. If the image is bad for some reason then I can
    always fall back to my incremental backups.


    What's recommended (if anything)?


    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Chris Green on Mon Aug 2 11:29:46 2021
    On 02/08/2021 10:29, Chris Green wrote:
    Recently (like last week-end) my Pi that runs local DNS died, I did an
    'apt update;apt upgrade', the /boot partition went read only and there
    was no kernel to boot from (the "7 short flashes" code from the LEDs
    was actually quite handy). Presumably the SD card failed in some way.

    I have good backups and was able to recover everything but it took
    quite a while (like Sunday morning) and, as a result I've been
    wondering if there's something I can do better.

    My existing backups are incremental backups taken daily of /etc and
    /home thus restoring the system meant that I got a new clean image,
    wrote my backups of /etc and /home to it and was back running again.
    However there were a few gotchas on the way, a few symbolic links from
    /etc had to be mended as well as installing some extra packages
    (fortunately I list packages I've added when I add them - very
    important!).


    So, what could I have done to make things quicker/easier?

    My incremental backups are automatic and run every night, when they're
    more than a month old the system weeds some of them out but I have
    monthly backups for some years back now. I'm not aiming to change this.

    However some sort of nightly 'image copy' would make what I had to do
    on Sunday much easier. It has to be automatic (i.e. run by anacron or
    cron) or it won't get done. This is a headless system so it has to
    be non-GUI too (with the advantage that as it's a "Lite" installation
    there's only about 1.5Gb of it to back up).

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it running quickly" backup I want, not the same as I have with the
    incremental backups. If the image is bad for some reason then I can
    always fall back to my incremental backups.


    What's recommended (if anything)?


    Well one way is to take the SD card out put it in a reader and take an image

    I am not sure if you can do that over a network in a live system.



    --
    Karl Marx said religion is the opium of the people.
    But Marxism is the crack cocaine.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to The Natural Philosopher on Mon Aug 2 11:46:48 2021
    The Natural Philosopher <tnp@invalid.invalid> wrote:
    On 02/08/2021 10:29, Chris Green wrote:
    Recently (like last week-end) my Pi that runs local DNS died, I did an
    'apt update;apt upgrade', the /boot partition went read only and there
    was no kernel to boot from (the "7 short flashes" code from the LEDs
    was actually quite handy). Presumably the SD card failed in some way.

    I have good backups and was able to recover everything but it took
    quite a while (like Sunday morning) and, as a result I've been
    wondering if there's something I can do better.

    My existing backups are incremental backups taken daily of /etc and
    /home thus restoring the system meant that I got a new clean image,
    wrote my backups of /etc and /home to it and was back running again. However there were a few gotchas on the way, a few symbolic links from
    /etc had to be mended as well as installing some extra packages (fortunately I list packages I've added when I add them - very
    important!).


    So, what could I have done to make things quicker/easier?

    My incremental backups are automatic and run every night, when they're
    more than a month old the system weeds some of them out but I have
    monthly backups for some years back now. I'm not aiming to change this.

    However some sort of nightly 'image copy' would make what I had to do
    on Sunday much easier. It has to be automatic (i.e. run by anacron or cron) or it won't get done. This is a headless system so it has to
    be non-GUI too (with the advantage that as it's a "Lite" installation there's only about 1.5Gb of it to back up).

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it running quickly" backup I want, not the same as I have with the
    incremental backups. If the image is bad for some reason then I can
    always fall back to my incremental backups.


    What's recommended (if anything)?


    Well one way is to take the SD card out put it in a reader and take an image

    That's a little difficult to automate! :-)

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Elvidge@3:770/3 to The Natural Philosopher on Mon Aug 2 11:56:49 2021
    On 02/08/2021 11:29 am, The Natural Philosopher wrote:
    On 02/08/2021 10:29, Chris Green wrote:
    Recently (like last week-end) my Pi that runs local DNS died, I did an
    'apt update;apt upgrade', the /boot partition went read only and there
    was no kernel to boot from (the "7 short flashes" code from the LEDs
    was actually quite handy). Presumably the SD card failed in some way.

    I have good backups and was able to recover everything but it took
    quite a while (like Sunday morning) and, as a result I've been
    wondering if there's something I can do better.

    My existing backups are incremental backups taken daily of /etc and
    /home thus restoring the system meant that I got a new clean image,
    wrote my backups of /etc and /home to it and was back running again.
    However there were a few gotchas on the way, a few symbolic links from
    /etc had to be mended as well as installing some extra packages
    (fortunately I list packages I've added when I add them - very
    important!).


    So, what could I have done to make things quicker/easier?

    My incremental backups are automatic and run every night, when they're
    more than a month old the system weeds some of them out but I have
    monthly backups for some years back now. I'm not aiming to change this.

    However some sort of nightly 'image copy' would make what I had to do
    on Sunday much easier. It has to be automatic (i.e. run by anacron or
    cron) or it won't get done. This is a headless system so it has to
    be non-GUI too (with the advantage that as it's a "Lite" installation
    there's only about 1.5Gb of it to back up).

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it
    running quickly" backup I want, not the same as I have with the
    incremental backups. If the image is bad for some reason then I can
    always fall back to my incremental backups.


    What's recommended (if anything)?


    Well one way is to take the SD card out put it in a reader and take an
    image

    I am not sure if you can do that over a network in a live system.




    You don't want an _image_ copy of a running system - there's all sorts
    of things you don't need/want copied - /dev /proc /sys etc.
    Just do an ssh/rsync --one-file-system from the backup machine.
    E.g.

    rsync --archive --one-file-system --exclude=lost+found --exclude=media --exclude=save --exclude=var/cache --exclude=swap --exclude=*~ --delete --delete-excluded --info=STATS1 "machine-to-backup:/" "directory-for-backup"


    --
    Chris Elvidge
    England
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to Chris Green on Mon Aug 2 11:36:26 2021
    On Mon, 2 Aug 2021 10:29:44 +0100
    Chris Green <cl@isbd.net> wrote:

    So, what could I have done to make things quicker/easier?

    There are many possibilities.

    Running from mirrored drives provides the fastest recovery from
    drive failure - not possible with SD cards on a Pi but should be possible booting over USB. You do need to check from time to time and replace bad
    drives promptly.

    Running a failover server provides the fastest recovery from system failure - setting up can be tricky and you need something to tell you when
    a system is down otherwise you may not notice until the failover goes down.

    Network booting everything from a central server is great and makes
    it easy to arrange snapshots - until the central server dies - so don't go
    that way unless you can afford to failover that server. It's also terrible
    for maintaining partial service on batteries in power outage.

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night,

    A better option is probably to keep a master image (several copies)
    and make a regular backup that is the increment against the master - then restoring is a bit like assembling a docker image. Copy the master and
    apply the latest increment.

    Whatever you do do not I implore you overwrite a single image every night. Murphy will ensure that the crash happens in the middle of that operation and then your system and the backup are hosed[1]. Keep at least
    two images.

    [1] This is not imagination - where I saw it happen they hadn't changed the backup tape in the several months the system had been there and the disc
    failed in the middle of the backup run. You should have seen the faces when
    I said "Where's last night's tape, this one is corrupt ?". They were
    *really* good at changing tapes and rotating the weeklies after that!

    --
    Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun
    The computer obeys and wins. | licences available see
    You lose and Bill collects. | http://www.sohara.org/
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to Chris Green on Mon Aug 2 12:28:38 2021
    Chris Green wrote on 02-08-2021 at 11:29:
    What's recommended (if anything)?

    Apart from any backup strategy: boot from a USB disk (SSD would be good)
    which almost certainly more reliable and probably faster than SD card.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to A. Dumas on Mon Aug 2 11:46:00 2021
    A. Dumas <alexandre@dumas.fr.invalid> wrote:
    Chris Green wrote on 02-08-2021 at 11:29:
    What's recommended (if anything)?

    Apart from any backup strategy: boot from a USB disk (SSD would be good) which almost certainly more reliable and probably faster than SD card.

    Yes, I'm considering that too! :-)

    Can an old Pi 2 boot from SSD? I know a Pi 4 can.

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Chris Elvidge on Mon Aug 2 12:23:39 2021
    Chris Elvidge <chris@mshome.net> wrote:

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it
    running quickly" backup I want, not the same as I have with the
    incremental backups. If the image is bad for some reason then I can
    always fall back to my incremental backups.


    What's recommended (if anything)?


    Well one way is to take the SD card out put it in a reader and take an image

    I am not sure if you can do that over a network in a live system.




    You don't want an _image_ copy of a running system - there's all sorts
    of things you don't need/want copied - /dev /proc /sys etc.
    Just do an ssh/rsync --one-file-system from the backup machine.
    E.g.

    rsync --archive --one-file-system --exclude=lost+found --exclude=media --exclude=save --exclude=var/cache --exclude=swap --exclude=*~ --delete --delete-excluded --info=STATS1 "machine-to-backup:/" "directory-for-backup"

    It needs far more than that for what I want to do.

    Apart from anything else there are two file systems to back up:-

    Filesystem Type 1M-blocks Used Avail Use% Mounted on
    /dev/root ext4 29270 1318 26731 5% /
    /dev/mmcblk0p1 vfat 253 49 205 20% /boot


    I want to have available some sort of clone/image of the system that I
    can quickly create a Pi SD image from. So the nightly backup will
    create a clone/image/whatever (on another system preferably) and from
    that clone/image/whatever I will be able to (quickly) create a working
    SD card to plug into the Pi.

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Ahem A Rivet's Shot on Mon Aug 2 12:30:10 2021
    Ahem A Rivet's Shot <steveo@eircom.net> wrote:
    On Mon, 2 Aug 2021 10:29:44 +0100
    Chris Green <cl@isbd.net> wrote:

    So, what could I have done to make things quicker/easier?

    There are many possibilities.

    Running from mirrored drives provides the fastest recovery from
    drive failure - not possible with SD cards on a Pi but should be possible booting over USB. You do need to check from time to time and replace bad drives promptly.

    That's overkill! :-)


    Running a failover server provides the fastest recovery from system failure - setting up can be tricky and you need something to tell you when
    a system is down otherwise you may not notice until the failover goes down.

    Similarly overkill.

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night,

    A better option is probably to keep a master image (several copies) and make a regular backup that is the increment against the master - then restoring is a bit like assembling a docker image. Copy the master and
    apply the latest increment.

    Yes, but this takes me to where I am already, it's essentially what I
    did when my Pi died. The 'master image' was simply a newly created Pi
    SD card and I applied my incremental changes. It was simple enough to
    do but did take some time.


    Whatever you do do not I implore you overwrite a single image every night. Murphy will ensure that the crash happens in the middle of that operation and then your system and the backup are hosed[1]. Keep at least
    two images.

    Maybe, but (as I said) if the overnight image is bad I simply fall
    back to what I did this time. I know it's sound and works, just takes
    a bit of time.


    What I'm after is a way to have a "ready to plug in" SD card that
    doesn't need any extra work on it before using it. Or, nearly as
    good, at least an image on disk that I can write to an SD card that
    will "just work".

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to Chris Green on Mon Aug 2 14:18:13 2021
    Chris Green wrote on 02-08-2021 at 12:46:
    Can an old Pi 2 boot from SSD? I know a Pi 4 can.

    Only the 2B v1.2, apparently: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

    But because it's not USB3 the speed is probably not better than SD card,
    I think, and an SSD might be overkill. Maybe a "high endurance" SD card
    would be a better investment.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Richard Kettlewell@3:770/3 to Chris Green on Mon Aug 2 12:35:16 2021
    Chris Green <cl@isbd.net> writes:
    My incremental backups are automatic and run every night, when they're
    more than a month old the system weeds some of them out but I have
    monthly backups for some years back now. I'm not aiming to change this.

    However some sort of nightly 'image copy' would make what I had to do
    on Sunday much easier. It has to be automatic (i.e. run by anacron or
    cron) or it won't get done. This is a headless system so it has to
    be non-GUI too (with the advantage that as it's a "Lite" installation
    there's only about 1.5Gb of it to back up).

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it running quickly" backup I want, not the same as I have with the
    incremental backups. If the image is bad for some reason then I can
    always fall back to my incremental backups.


    What's recommended (if anything)?

    I don’t know of a good tool to make image backups as such, though it’s going to boil down to something equivalent to

    ssh root@pi cat /dev/mmcblk0 > /path/to/backup.img

    ...done when the system is idle (if there’s lot of IO going on then the filesystem inside the image will be internally inconsistent).

    I had to restore a Pi from backups recently after the SD card failed.
    My backups are whole-system backups made with rsync, so once I’d figured
    out what shape the partitions should be in order to be bootable, it was straightforward to restore the backup onto the new card. It worked first
    time.


    IMO the requirement for an SD card is a weakness in the Pi design, due
    to their poor reliability. I don’t know what best alternative approach
    is, though, given the need to keep cost and physical size down while
    remaining flexible.

    --
    https://www.greenend.org.uk/rjk/
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to A. Dumas on Mon Aug 2 13:48:18 2021
    A. Dumas <alexandre@dumas.fr.invalid> wrote:
    Chris Green wrote on 02-08-2021 at 12:46:
    Can an old Pi 2 boot from SSD? I know a Pi 4 can.

    Only the 2B v1.2, apparently: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

    But because it's not USB3 the speed is probably not better than SD card,
    I think, and an SSD might be overkill. Maybe a "high endurance" SD card
    would be a better investment.

    Which is sort of where I came in. :-)

    How do I make (and maintain up to date) an image of the SD card?

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Richard Kettlewell on Mon Aug 2 13:56:15 2021
    Richard Kettlewell <invalid@invalid.invalid> wrote:
    Chris Green <cl@isbd.net> writes:
    My incremental backups are automatic and run every night, when they're
    more than a month old the system weeds some of them out but I have
    monthly backups for some years back now. I'm not aiming to change this.

    However some sort of nightly 'image copy' would make what I had to do
    on Sunday much easier. It has to be automatic (i.e. run by anacron or cron) or it won't get done. This is a headless system so it has to
    be non-GUI too (with the advantage that as it's a "Lite" installation there's only about 1.5Gb of it to back up).

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it running quickly" backup I want, not the same as I have with the
    incremental backups. If the image is bad for some reason then I can
    always fall back to my incremental backups.


    What's recommended (if anything)?

    I don’t know of a good tool to make image backups as such, though it’s going to boil down to something equivalent to

    ssh root@pi cat /dev/mmcblk0 > /path/to/backup.img

    ...done when the system is idle (if there’s lot of IO going on then the filesystem inside the image will be internally inconsistent).

    I had to restore a Pi from backups recently after the SD card failed.
    My backups are whole-system backups made with rsync, so once I’d figured out what shape the partitions should be in order to be bootable, it was straightforward to restore the backup onto the new card. It worked first time.

    So it looks like the way to go is simply to create a new SD card with
    the Lite OS on it and then rsync all the files from the running system
    to that card (less a few things as noted elswehere in this thread).

    I guess that's not so difficult to automate.


    IMO the requirement for an SD card is a weakness in the Pi design, due
    to their poor reliability. I don’t know what best alternative approach
    is, though, given the need to keep cost and physical size down while remaining flexible.

    The BeagleBone Black has an on-board eMMC memory with an SD slot as an alternative, I don't know if the eMMC is inherently any better than an
    external SD though.

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From nev young@3:770/3 to Chris Green on Mon Aug 2 14:53:45 2021
    On 02/08/2021 10:29, Chris Green wrote:
    So, what could I have done to make things quicker/easier?

    My incremental backups are automatic and run every night, when they're
    more than a month old the system weeds some of them out but I have
    monthly backups for some years back now. I'm not aiming to change this.

    However some sort of nightly 'image copy' would make what I had to do
    on Sunday much easier. It has to be automatic (i.e. run by anacron or
    cron) or it won't get done. This is a headless system so it has to
    be non-GUI too (with the advantage that as it's a "Lite" installation
    there's only about 1.5Gb of it to back up).

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it running quickly" backup I want, not the same as I have with the
    incremental backups. If the image is bad for some reason then I can
    always fall back to my incremental backups.


    What's recommended (if anything)?


    I use timeshift on my main PC and laptops.

    I make the backups on a different slab of spinning rust to the system
    disk, obviously.
    I believe it can be configured to use a network drive for the backups
    and I see it is available in the PI repository.

    On the few occasions I have needed to recover a system it has worked
    very well.

    --
    Nev
    It causes me a great deal of regret and remorse
    that so many people are unable to understand what I write.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Stefan Kaintoch@3:770/3 to Chris Green on Mon Aug 2 16:00:15 2021
    Chris Green <cl@isbd.net> wrote:
    So, what could I have done to make things quicker/easier?

    Try to separate things into read-only (preferably all things needed to
    boot and run the system) and read-write (home, ...). Then put the
    read-write stuff on storage other than a sd-card, e.g. hdd.
    Make a image of the read-only sd-card, and daily backups of the other
    stuff.

    HTH, Stefan
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Richard Falken@1:123/115 to Chris Green on Mon Aug 2 10:07:25 2021
    Re: Disaster recovery, how to automate as far as possible?
    By: Chris Green to All on Mon Aug 02 2021 10:29 am

    I have good backups and was able to recover everything but it took
    quite a while (like Sunday morning) and, as a result I've been
    wondering if there's something I can do better.


    It depends on your need for availability. I suppose you don't want to do anything complex. I assume you are'nt using any CoW filesystem or snapshotting volume manager in your pi.

    You cannot really take an SD card snapshop from a running system without risking bad problems. To the point problems are close to guaranteed, unless you use some snapshotting system.

    I personally use a cronjob that turns off the services that may perform changes on the filesystems and them dump the filesystems sequentially over a network for my personal servers. The drawback is the services go down while you back them up. Thankfully my personal servers don't need 24/7 availability and the backup will be done and the services operational once again when needed. You can script a backup service that dumps the filesystems of the pi to an SD card over a network and then sets a bootloader for it, but sincerely I think it is more trouble than it is worth.

    --
    gopher://gopher.richardfalken.com/1/richardfalken
    --- SBBSecho 3.14-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)
  • From Richard Falken@1:123/115 to Chris Elvidge on Mon Aug 2 10:08:50 2021
    Re: Re: Disaster recovery, how to automate as far as possible?
    By: Chris Elvidge to The Natural Philosopher on Mon Aug 02 2021 11:56 am

    You don't want an _image_ copy of a running system - there's all sorts
    of things you don't need/want copied - /dev /proc /sys etc.
    Just do an ssh/rsync --one-file-system from the backup machine.
    E.g.

    rsync --archive --one-file-system --exclude=lost+found --exclude=media --exclude=save --exclude=var/cache --exclude=swap --exclude=*~ --delete --delete-excluded --info=STATS1 "machine-to-backup:/" "directory-for-backup"


    Yeah, but he wants a bootable backup image I think.

    Also rsyncing a live system may cause inconsistencies in the backup image. You have to be careful with those.

    --
    gopher://gopher.richardfalken.com/1/richardfalken
    --- SBBSecho 3.14-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)
  • From Martin Gregorie@3:770/3 to Chris Green on Mon Aug 2 14:52:34 2021
    On Mon, 02 Aug 2021 12:23:39 +0100, Chris Green wrote:

    Chris Elvidge <chris@mshome.net> wrote:

    Is there some sort of "make an image copy of this system" I can run
    on the Pi to write an image to another system? I'd just keep a
    single image I think and overwrite it every night, it's a "restore
    and get it running quickly" backup I want, not the same as I have
    with the incremental backups. If the image is bad for some reason
    then I can always fall back to my incremental backups.


    What's recommended (if anything)?


    Well one way is to take the SD card out put it in a reader and take
    an image

    I am not sure if you can do that over a network in a live system.




    You don't want an _image_ copy of a running system - there's all sorts
    of things you don't need/want copied - /dev /proc /sys etc.
    Just do an ssh/rsync --one-file-system from the backup machine.
    E.g.

    rsync --archive --one-file-system --exclude=lost+found --exclude=media
    --exclude=save --exclude=var/cache --exclude=swap --exclude=*~ --delete
    --delete-excluded --info=STATS1 "machine-to-backup:/"
    "directory-for-backup"

    It needs far more than that for what I want to do.

    Apart from anything else there are two file systems to back up:-

    Filesystem Type 1M-blocks Used Avail Use% Mounted on /dev/root
    ext4 29270 1318 26731 5% / /dev/mmcblk0p1 vfat 253
    49 205 20% /boot


    Set up your backup cards (use at least two and cycle them), using the
    same partition scheme as your prime card) and run rsync twice (once on
    each partition for each backup session) because that's fast - if there
    are no changes, rsync only scans the partition being backed up.

    If you install your locally developed scripts, programs and man pages in
    the /usr/local/* file structure, make sure thats backed up too.

    BTW, full marks for keeping a list of the extra packages you've
    installed, but have you thought of structuring that list as a script
    containing a list of "apt get package-name" statements? Its a nice, zero-
    cost way of speeding up disaster recovery.

    I want to have available some sort of clone/image of the system that I
    can quickly create a Pi SD image from. So the nightly backup will
    create a clone/image/whatever (on another system preferably) and from
    that clone/image/whatever I will be able to (quickly) create a working
    SD card to plug into the Pi.

    Using rsync the way I've suggested will do that: cloning the backup disk
    then requires:
    - creating the two partitions on the new disk
    - running dd to copy their contents to the new disk.


    --
    Martin | martin at
    Gregorie | gregorie dot org
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to Chris Green on Mon Aug 2 15:05:46 2021
    Chris Green <cl@isbd.net> wrote:
    A. Dumas <alexandre@dumas.fr.invalid> wrote:
    Chris Green wrote on 02-08-2021 at 12:46:
    Can an old Pi 2 boot from SSD? I know a Pi 4 can.

    Only the 2B v1.2, apparently:
    https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

    But because it's not USB3 the speed is probably not better than SD card,
    I think, and an SSD might be overkill. Maybe a "high endurance" SD card
    would be a better investment.

    Which is sort of where I came in. :-)

    Well, a high quality high endurance sd card would certainly be an
    additional benefit.

    How do I make (and maintain up to date) an image of the SD card?

    I don't think you can get much closer than you already are, except with
    that other suggestion: mirrored disks, which you rightly deemed to be
    overkill. You can however dramatically accelerate the restore from fresh
    image with something like Ansible playbooks (or your own bash script implementation).
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Anssi Saari@3:770/3 to Chris Green on Mon Aug 2 18:11:53 2021
    Chris Green <cl@isbd.net> writes:

    Chris Elvidge <chris@mshome.net> wrote:

    rsync --archive --one-file-system --exclude=lost+found --exclude=media
    --exclude=save --exclude=var/cache --exclude=swap --exclude=*~ --delete
    --delete-excluded --info=STATS1 "machine-to-backup:/" "directory-for-backup" >>
    It needs far more than that for what I want to do.

    Actually I'd say that's a large part of it. I'll sketch here how you
    could make an image of your Pi:

    - Create an empty file the size of your SD card or at least large enough
    to hold the file systems.
    - Put your partition table from Pi's SD card on there and create the
    root file system.
    - On my Pi at least the /boot partition on a Pi can be unmounted during
    runtime so you can do that and then image it directly into your backup
    SD card image and remount. Offset calculation left as an exercise.
    - For the / partition, mount your corresponding partition inside the SD
    card image and use the rsync stanza from your namesake above.

    And that should do it. I've never done this exactly but I don't see an
    issue either. You could even use a real SD card as the target instead of
    an image but if you do it every night it might eat up the card...

    For a more advanced solution you could go to the zfs filesystem and use
    the snapshot feature there. I don't know zfs nearly well enough to do
    that though.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to nev young on Mon Aug 2 15:51:17 2021
    nev young <newsforpasiphae1953@yahoo.co.uk> wrote:
    On 02/08/2021 10:29, Chris Green wrote:
    So, what could I have done to make things quicker/easier?

    My incremental backups are automatic and run every night, when they're
    more than a month old the system weeds some of them out but I have
    monthly backups for some years back now. I'm not aiming to change this.

    However some sort of nightly 'image copy' would make what I had to do
    on Sunday much easier. It has to be automatic (i.e. run by anacron or cron) or it won't get done. This is a headless system so it has to
    be non-GUI too (with the advantage that as it's a "Lite" installation there's only about 1.5Gb of it to back up).

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it running quickly" backup I want, not the same as I have with the
    incremental backups. If the image is bad for some reason then I can
    always fall back to my incremental backups.


    What's recommended (if anything)?


    I use timeshift on my main PC and laptops.

    I make the backups on a different slab of spinning rust to the system
    disk, obviously.
    I believe it can be configured to use a network drive for the backups
    and I see it is available in the PI repository.

    On the few occasions I have needed to recover a system it has worked
    very well.

    It doesn't do what I want though.

    Its basic function in life is to restore your system to how it was
    some time ago, hence its name. (I.e. it does incremental backups,
    just like I do already, and very handy they are too)

    It doesn't do remote backups/copies (which I'd prefer, though not
    essential).

    It doesn't provide a restore for a non-bootable system, you have to
    create a bootable system, install timeshift on that and then do a
    restore. That's as much work as my restoring from my home-made
    incremental backups.


    I repeat! :-) :-) :-)

    I want a system that provides me with either a ready to boot SD card
    with my current system on it or, an 'image' that I can quickly copy to
    an SD card and can boot.

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Stefan Kaintoch on Mon Aug 2 15:57:49 2021
    Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
    Chris Green <cl@isbd.net> wrote:
    So, what could I have done to make things quicker/easier?

    Try to separate things into read-only (preferably all things needed to
    boot and run the system) and read-write (home, ...). Then put the
    read-write stuff on storage other than a sd-card, e.g. hdd.
    Make a image of the read-only sd-card, and daily backups of the other
    stuff.

    ... and how do I quickly restore from that? You've effectively
    described what I already do with my incremental backups. I do daily incremental backups of everything that changes.

    My issue was it took a while to:-

    Create a clean new Pi system
    Add/move users as required
    do 'apt update;apt upgrade'
    restore /etc and /home from my incremental backups


    That's pretty much what it would take to restore from the backups
    you're suggesting above.

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From nev young@3:770/3 to Chris Green on Mon Aug 2 17:19:17 2021
    On 02/08/2021 15:57, Chris Green wrote:
    Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
    Chris Green <cl@isbd.net> wrote:
    So, what could I have done to make things quicker/easier?

    Try to separate things into read-only (preferably all things needed to
    boot and run the system) and read-write (home, ...). Then put the
    read-write stuff on storage other than a sd-card, e.g. hdd.
    Make a image of the read-only sd-card, and daily backups of the other
    stuff.

    ... and how do I quickly restore from that? You've effectively
    described what I already do with my incremental backups. I do daily incremental backups of everything that changes.

    My issue was it took a while to:-

    Create a clean new Pi system
    Add/move users as required
    do 'apt update;apt upgrade'
    restore /etc and /home from my incremental backups


    That's pretty much what it would take to restore from the backups
    you're suggesting above.

    I'm assuming you want to get up and running ASAP after a disaster?
    So I would prepare for it by doing your normal incremental backups
    then copying them (at your leisure) to a (or many) spare SD Card at
    regular intervals.
    Then when the inevitable happens you should only need to swap the most
    recent backup SD card into the dead Pi.

    Or have I still not got what you want right in my head?

    --
    Nev
    It causes me a great deal of regret and remorse
    that so many people are unable to understand what I write.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to Chris Green on Mon Aug 2 16:45:51 2021
    On 02/08/2021 15:51, Chris Green wrote:
    nev young <newsforpasiphae1953@yahoo.co.uk> wrote:
    On 02/08/2021 10:29, Chris Green wrote:
    So, what could I have done to make things quicker/easier?

    My incremental backups are automatic and run every night, when they're
    more than a month old the system weeds some of them out but I have
    monthly backups for some years back now. I'm not aiming to change this. >>>
    However some sort of nightly 'image copy' would make what I had to do
    on Sunday much easier. It has to be automatic (i.e. run by anacron or
    cron) or it won't get done. This is a headless system so it has to
    be non-GUI too (with the advantage that as it's a "Lite" installation
    there's only about 1.5Gb of it to back up).

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it
    running quickly" backup I want, not the same as I have with the
    incremental backups. If the image is bad for some reason then I can
    always fall back to my incremental backups.


    What's recommended (if anything)?


    I use timeshift on my main PC and laptops.

    I make the backups on a different slab of spinning rust to the system
    disk, obviously.
    I believe it can be configured to use a network drive for the backups
    and I see it is available in the PI repository.

    On the few occasions I have needed to recover a system it has worked
    very well.

    It doesn't do what I want though.

    Its basic function in life is to restore your system to how it was
    some time ago, hence its name. (I.e. it does incremental backups,
    just like I do already, and very handy they are too)

    It doesn't do remote backups/copies (which I'd prefer, though not
    essential).

    It doesn't provide a restore for a non-bootable system, you have to
    create a bootable system, install timeshift on that and then do a
    restore. That's as much work as my restoring from my home-made
    incremental backups.


    I repeat! :-) :-) :-)

    I want a system that provides me with either a ready to boot SD card
    with my current system on it or, an 'image' that I can quickly copy to
    an SD card and can boot.


    Instead of automatic system backups you could look at
    automatic/simplified provisioning. i.e. taking a standard OS image and automatically installing/configuring everything you need.

    You still need to backup your data, but backing up the OS is a bit old fashioned.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Jackson@3:770/3 to All on Mon Aug 2 16:19:43 2021
    Can an old Pi 2 boot from SSD? I know a Pi 4 can.

    Only the 2B v1.2, apparently:
    https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

    But because it's not USB3 the speed is probably not better than SD card,

    It is faster then the SD card. The SD card interface is not particularly
    fast.

    I think, and an SSD might be overkill. Maybe a "high endurance" SD card
    would be a better investment.

    Which is sort of where I came in. :-)

    I have 2 Pi servers, a Pi3B and an old Pi1b+.

    Each boots from it's SD card, but the cmdline.txt specifies that the
    root filesystem is on the USB attached HD (spinning rust). The disks are
    both WD disks with built in USB2 interface.

    I have it so the sd card /boot partition is mounted readonly, and there
    is a second SD partition (usually unmounted) where I keep a copy of the
    root partition on the USB disk. An rsync script(*) running at least daily, mounts the SDcard 2nd part. and updates it from the running root
    partition, then unmounts. That way the SD card is only "at risk" during
    the update. I get aprox. 1.3MB per day updates - log files mostly.

    If the harddrive dies I will take out the SD card and on my desktop
    computer alter the cmdline.txt file to specify root on the SD card -
    alter the /etc/fstab file as needed - but back in Pi and reboot.
    Then go about replacing the failed HD.

    The other data partitions on the Harddrive are backuped up elsewhere and
    would have to be restored onto any replacement USB disk, along with a
    copy of the root partition.

    I use rsync for my backup purposes, and have recovered my Linux Intel
    desktop when it's boot disk died, using a similar scheme (it has 2 disks
    - but grub is a Bl**dy can of worms and a grub rescue CD was needed).

    Jim

    (*) make sure you specify the -XAH options to rsync as well as the usual
    -a and -x (don't cross file system boundaries), and whatever delete
    option you prefer.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Deloptes@3:770/3 to Chris Green on Mon Aug 2 18:23:03 2021
    Chris Green wrote:

    I repeat! :-) :-) :-)

    I want a system that provides me with either a ready to boot SD card
    with my current system on it or, an 'image' that I can quickly copy to
    an SD card and can boot.

    aaah didn't follow closer this thread, but it is continuing for some time
    now
    If you want to keep the SD card ... then just replicate the SD card to the backup and prepare to write back whenever needed.

    BTW borg backup does deduplication and is very space efficient. I already restored one CFLASH card when the old one suddenly died on the firewall. Needless to say you need a second machine anyway for doing the restore and a USB adapter etc.

    The best way to deal with root system backups is lvm snapshots - you have to plan this before partitioning. It pays off at the end.

    I solved the problem in my case by eliminating the SD card. I configured the RPis for diskless boot from the server. On the server changing things is a peanut butter. I guess each avg. NAS can do this, so it does not have to be expensive and power consuming machine - it is sufficient to have linux on
    it. A single SD card is and will remain the risk in the equation.
    But if you insist using SD card for whatever reason, better have a ready to
    use copy in your pocket. Not that they are so bad, but you don't know when exactly it will fail
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Mon Aug 2 12:48:50 2021
    On Mon, 2 Aug 2021 13:56:15 +0100, Chris Green <cl@isbd.net> declaimed the following:

    The BeagleBone Black has an on-board eMMC memory with an SD slot as an >alternative, I don't know if the eMMC is inherently any better than an >external SD though.

    Depends on the SD card, to some extant. I've seen one with quite atrocious I/O, even though it was "rated" faster than some slower SanDisk.

    Class 10 cards are rated on streaming a single file to a freshly formatted card [video]; Class 2/4/6 are based on multiple short files,
    possibly including fragmentation from deletes [still image cameras]. As a result, higher end Class 4/6 cards can easily out-perform a cheaper Class
    10 whose internal controller was optimized for FAT and streaming (only two "allocation unit" buffers; if jumping around for small files, the card is continuously updating allocation units).


    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dennis Lee Bieber@3:770/3 to All on Mon Aug 2 12:52:57 2021
    On Mon, 2 Aug 2021 15:57:49 +0100, Chris Green <cl@isbd.net> declaimed the following:

    Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
    Chris Green <cl@isbd.net> wrote:
    So, what could I have done to make things quicker/easier?

    Try to separate things into read-only (preferably all things needed to
    boot and run the system) and read-write (home, ...). Then put the
    read-write stuff on storage other than a sd-card, e.g. hdd.
    Make a image of the read-only sd-card, and daily backups of the other
    stuff.

    ... and how do I quickly restore from that? You've effectively
    described what I already do with my incremental backups. I do daily >incremental backups of everything that changes.

    My issue was it took a while to:-

    Create a clean new Pi system
    Add/move users as required
    do 'apt update;apt upgrade'
    restore /etc and /home from my incremental backups


    That's pretty much what it would take to restore from the backups
    you're suggesting above.

    No... /etc and /home would be on the external hard-drive -- no restore for their contents, unless the hard-drive itself fails. If the SD card
    fails, you swap the card and reboot. You do have to keep the SD card image up-to-date -- so periodic swapping to run the apt update/upgrade cycle may
    be recommended.


    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Richard Falken on Mon Aug 2 17:51:54 2021
    Richard Falken <nospam.Richard.Falken@f1.n770.z8209.fidonet.org> wrote:
    Re: Disaster recovery, how to automate as far as possible?
    By: Chris Green to All on Mon Aug 02 2021 10:29 am

    I have good backups and was able to recover everything but it took
    quite a while (like Sunday morning) and, as a result I've been
    wondering if there's something I can do better.


    It depends on your need for availability. I suppose you don't want to do anything complex. I assume you are'nt using any CoW filesystem or snapshotting
    volume manager in your pi.

    You cannot really take an SD card snapshop from a running system without risking bad problems. To the point problems are close to guaranteed, unless you
    use some snapshotting system.

    I personally use a cronjob that turns off the services that may perform changes
    on the filesystems and them dump the filesystems sequentially over a network for my personal servers. The drawback is the services go down while you back them up. Thankfully my personal servers don't need 24/7 availability and the backup will be done and the services operational once again when needed. You can script a backup service that dumps the filesystems of the pi to an SD card
    over a network and then sets a bootloader for it, but sincerely I think it is more trouble than it is worth.

    The Pi I want to back up runs only DNS/DHCP for my LAN, there are
    other services running but none are actually in use.

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to nev young on Mon Aug 2 17:57:55 2021
    nev young <newsforpasiphae1953@yahoo.co.uk> wrote:
    On 02/08/2021 15:57, Chris Green wrote:
    Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
    Chris Green <cl@isbd.net> wrote:
    So, what could I have done to make things quicker/easier?

    Try to separate things into read-only (preferably all things needed to
    boot and run the system) and read-write (home, ...). Then put the
    read-write stuff on storage other than a sd-card, e.g. hdd.
    Make a image of the read-only sd-card, and daily backups of the other
    stuff.

    ... and how do I quickly restore from that? You've effectively
    described what I already do with my incremental backups. I do daily incremental backups of everything that changes.

    My issue was it took a while to:-

    Create a clean new Pi system
    Add/move users as required
    do 'apt update;apt upgrade'
    restore /etc and /home from my incremental backups


    That's pretty much what it would take to restore from the backups
    you're suggesting above.

    I'm assuming you want to get up and running ASAP after a disaster?
    So I would prepare for it by doing your normal incremental backups
    then copying them (at your leisure) to a (or many) spare SD Card at
    regular intervals.
    Then when the inevitable happens you should only need to swap the most
    recent backup SD card into the dead Pi.

    Or have I still not got what you want right in my head?

    You have it right, that's most of what I want to do.

    The only thing is that I want to automate "... copying them (at your
    leisure) to a (or many) spare SD Card at regular intervals", I suppose
    this is do-able though. I *know* it won't get done otherwise! :-)

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Peter@3:770/3 to Chris Green on Mon Aug 2 18:14:09 2021
    On 02/08/2021 10:29, Chris Green wrote:
    Recently (like last week-end) my Pi that runs local DNS died, I did an
    'apt update;apt upgrade', the /boot partition went read only and there
    was no kernel to boot from (the "7 short flashes" code from the LEDs
    was actually quite handy). Presumably the SD card failed in some way.

    I have good backups and was able to recover everything but it took
    quite a while (like Sunday morning) and, as a result I've been
    wondering if there's something I can do better.

    My existing backups are incremental backups taken daily of /etc and
    /home thus restoring the system meant that I got a new clean image,
    wrote my backups of /etc and /home to it and was back running again.
    However there were a few gotchas on the way, a few symbolic links from
    /etc had to be mended as well as installing some extra packages
    (fortunately I list packages I've added when I add them - very
    important!).


    So, what could I have done to make things quicker/easier?

    My incremental backups are automatic and run every night, when they're
    more than a month old the system weeds some of them out but I have
    monthly backups for some years back now. I'm not aiming to change this.

    However some sort of nightly 'image copy' would make what I had to do
    on Sunday much easier. It has to be automatic (i.e. run by anacron or
    cron) or it won't get done. This is a headless system so it has to
    be non-GUI too (with the advantage that as it's a "Lite" installation
    there's only about 1.5Gb of it to back up).

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it running quickly" backup I want, not the same as I have with the
    incremental backups. If the image is bad for some reason then I can
    always fall back to my incremental backups.


    What's recommended (if anything)?



    Does rpi-clone do what you want? Scripting for rsync with lots of
    options for cloning an SD card

    https://github.com/billw2/rpi-clone
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Scott Alfter@3:770/3 to Richard Falken on Mon Aug 2 17:52:23 2021
    In article <627925140@f1.n770.z8210.fidonet.org>,
    Richard Falken <nospam.Richard.Falken@f1.n770.z8210.fidonet.org> wrote:
    Re: Re: Disaster recovery, how to automate as far as possible?
    By: Chris Elvidge to The Natural Philosopher on Mon Aug 02 2021 11:56 am

    You don't want an _image_ copy of a running system - there's all sorts
    of things you don't need/want copied - /dev /proc /sys etc.
    Just do an ssh/rsync --one-file-system from the backup machine.
    E.g.

    rsync --archive --one-file-system --exclude=lost+found --exclude=media --exclude=save --exclude=var/cache --exclude=swap --exclude=*~ --delete --delete-excluded --info=STATS1 "machine-to-backup:/" "directory-for-backup"


    Yeah, but he wants a bootable backup image I think.

    I don't think you're going to get that with any kind of online backup. I
    image Raspberry Pi systems by popping out the SD card, shrinking the root filesystem as small as possible with gparted (running on another computer),
    and piping dd into xz (or gzip if I'm in a hurry) to make an image backup. Clonezilla would probably work too, but it's a bit trickier to use if you
    need to restore to a smaller SD card.

    _/_
    / v \ Scott Alfter (remove the obvious to send mail)
    (IIGS( https://alfter.us/ Top-posting!
    \_^_/ >What's the most annoying thing on Usenet? --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Dennis Lee Bieber on Mon Aug 2 18:39:55 2021
    Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
    That's pretty much what it would take to restore from the backups
    you're suggesting above.

    No... /etc and /home would be on the external hard-drive -- no restore
    for their contents, unless the hard-drive itself fails. If the SD card
    fails, you swap the card and reboot. You do have to keep the SD card image up-to-date -- so periodic swapping to run the apt update/upgrade cycle may
    be recommended.

    You can't automate "periodic swapping", so (knowing me) it won't get
    done.

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Peter on Mon Aug 2 18:41:22 2021
    Peter <user@domain.invalid> wrote:
    On 02/08/2021 10:29, Chris Green wrote:
    Recently (like last week-end) my Pi that runs local DNS died, I did an
    'apt update;apt upgrade', the /boot partition went read only and there
    was no kernel to boot from (the "7 short flashes" code from the LEDs
    was actually quite handy). Presumably the SD card failed in some way.

    I have good backups and was able to recover everything but it took
    quite a while (like Sunday morning) and, as a result I've been
    wondering if there's something I can do better.

    My existing backups are incremental backups taken daily of /etc and
    /home thus restoring the system meant that I got a new clean image,
    wrote my backups of /etc and /home to it and was back running again. However there were a few gotchas on the way, a few symbolic links from
    /etc had to be mended as well as installing some extra packages (fortunately I list packages I've added when I add them - very
    important!).


    So, what could I have done to make things quicker/easier?

    My incremental backups are automatic and run every night, when they're
    more than a month old the system weeds some of them out but I have
    monthly backups for some years back now. I'm not aiming to change this.

    However some sort of nightly 'image copy' would make what I had to do
    on Sunday much easier. It has to be automatic (i.e. run by anacron or cron) or it won't get done. This is a headless system so it has to
    be non-GUI too (with the advantage that as it's a "Lite" installation there's only about 1.5Gb of it to back up).

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it running quickly" backup I want, not the same as I have with the
    incremental backups. If the image is bad for some reason then I can
    always fall back to my incremental backups.


    What's recommended (if anything)?



    Does rpi-clone do what you want? Scripting for rsync with lots of
    options for cloning an SD card

    https://github.com/billw2/rpi-clone

    Yes, I think it's about the closest to what I want that I've come
    across. It's just a long bash script so I can some/all of it if I
    decide to roll my own.

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to Chris Green on Mon Aug 2 18:28:10 2021
    On Mon, 02 Aug 2021 18:39:55 +0100, Chris Green wrote:

    Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
    That's pretty much what it would take to restore from the backups
    you're suggesting above.

    No... /etc and /home would be on the external hard-drive -- no
    restore
    for their contents, unless the hard-drive itself fails. If the SD card
    fails, you swap the card and reboot. You do have to keep the SD card
    image up-to-date -- so periodic swapping to run the apt update/upgrade
    cycle may be recommended.

    You can't automate "periodic swapping", so (knowing me) it won't get
    done.

    But, almost as fast as using rsync, I think (disclaimer: not tried) would
    be to write a bash script that:

    - wipes and recreates the two partitions on the backup SD card with the
    same names as the corresponding partitions on the live SD card
    - uses dd to copy both partitions from live to backup card.

    Thats pretty much what I did last time I migrated a working RPi filing
    system to a larger SD card, except that it was done manually rather than
    run by a bash script. The new card was bootable without further hackery,
    so maybe that would offer a better way to make a bootable backup.

    I don't recall that being a particularly slow process. However, even if
    it is slow, running it overnight as a cron job would make its speed
    irrelevant.


    --
    Martin | martin at
    Gregorie | gregorie dot org
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Richard Falken@1:123/115 to Chris Green on Mon Aug 2 15:19:41 2021
    Re: Re: Disaster recovery, how to automate as far as possible?
    By: Chris Green to Richard Falken on Mon Aug 02 2021 05:51 pm

    The Pi I want to back up runs only DNS/DHCP for my LAN, there are
    other services running but none are actually in use.

    --
    Chris Green

    Then, your work is easy.

    Get PiCore. It is a Tiny Core Linux port for the Raspberry Pi. YOu can configure it to boot from the SD card, copy the whole operating system to RAM, and then forget the SD card exists.

    You just remaster the SD card with the configuration you want for your DNS and DHCP. The content of the SD card is never changed. There is no data persistence unless you manually -or scriptedly- command the OS to copy data to disk.

    This allows you to have a BASE operating system which never changes stored in the SD. If there is data you want to save, you trigger a "store to disk" command, which saves the changes between the running system in RAM and the base system in the SD as a tar file.

    And then you can send that tar file over a network.

    Which is GREAT because you may have two PiCore SDs ready, use one for production, command it to save the tar overlay every 24 hours and send the tar to a backup server periodically. If you ever need to recover using the second SD, you just copy the tar file to the second SD and boot. Just copy. No imaging, no uncompressing, no anything.

    Still I recommend the backup to be done with services stopped.

    --
    gopher://gopher.richardfalken.com/1/richardfalken
    --- SBBSecho 3.14-Linux
    * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)
  • From Stefan Kaintoch@3:770/3 to Chris Green on Tue Aug 3 07:18:45 2021
    Chris Green <cl@isbd.net> wrote:
    Stefan Kaintoch <stefan@ratri.rincewind.kaintoch.de> wrote:
    Chris Green <cl@isbd.net> wrote:
    So, what could I have done to make things quicker/easier?

    Try to separate things into read-only (preferably all things needed to
    boot and run the system) and read-write (home, ...). Then put the
    read-write stuff on storage other than a sd-card, e.g. hdd.
    Make a image of the read-only sd-card, and daily backups of the other
    stuff.

    ... and how do I quickly restore from that? You've effectively
    described what I already do with my incremental backups. I do daily incremental backups of everything that changes.

    Copy the image to a new sd-card (or have already one prepared) and
    re-attach the read-write storage to the pi. That's work for 10 minutes.
    It won't get much faster.

    There's one thing I didn't mention: don't do frequent apt update/upgrade cycles. Otherwise separation into read-write and read-only doesn't make
    too much sense. If you want frequent upgrades use only a hdd as storage
    and boot from it.

    My issue was it took a while to:-

    Create a clean new Pi system
    Add/move users as required
    do 'apt update;apt upgrade'

    These three steps are not necessary if you have an image of the
    read-only stuff. Just dd the image to an sd-card and put it in the pi.

    restore /etc and /home from my incremental backups

    That's not necessary. Just reattach the read-write storage.

    That's pretty much what it would take to restore from the backups
    you're suggesting above.

    Only the read-write storage.
    And that may even be a ramdisk in the pi's RAM.
    You can even write a script which automatically creates the ramdisk and
    fills it from the read-write backup at boot-time. If done so, recovery
    desaster is just putting a prepared sd-card into the pi and booting (10 seconds).

    HTH, Stefan
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Richard Falken on Tue Aug 3 08:41:58 2021
    Richard Falken <nospam.Richard.Falken@f1.n770.z8232.fidonet.org> wrote:
    Re: Re: Disaster recovery, how to automate as far as possible?
    By: Chris Green to Richard Falken on Mon Aug 02 2021 05:51 pm

    The Pi I want to back up runs only DNS/DHCP for my LAN, there are
    other services running but none are actually in use.

    --
    Chris Green

    Then, your work is easy.

    Get PiCore. It is a Tiny Core Linux port for the Raspberry Pi. YOu can configure it to boot from the SD card, copy the whole operating system to RAM,
    and then forget the SD card exists.

    You just remaster the SD card with the configuration you want for your DNS and
    DHCP. The content of the SD card is never changed. There is no data persistence
    unless you manually -or scriptedly- command the OS to copy data to disk.

    This allows you to have a BASE operating system which never changes stored in the SD. If there is data you want to save, you trigger a "store to disk" command, which saves the changes between the running system in RAM and the base
    system in the SD as a tar file.

    And then you can send that tar file over a network.

    Which is GREAT because you may have two PiCore SDs ready, use one for production, command it to save the tar overlay every 24 hours and send the tar
    to a backup server periodically. If you ever need to recover using the second SD, you just copy the tar file to the second SD and boot. Just copy. No imaging, no uncompressing, no anything.

    Still I recommend the backup to be done with services stopped.

    Now that is quite a neat idea, thank you.

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Chris Green on Tue Aug 3 15:02:47 2021
    On 02/08/2021 10:29, Chris Green wrote:
    So, what could I have done to make things quicker/easier?

    My incremental backups are automatic and run every night, when they're
    more than a month old the system weeds some of them out but I have
    monthly backups for some years back now. I'm not aiming to change this.

    However some sort of nightly 'image copy' would make what I had to do
    on Sunday much easier. It has to be automatic (i.e. run by anacron or
    cron) or it won't get done. This is a headless system so it has to
    be non-GUI too (with the advantage that as it's a "Lite" installation
    there's only about 1.5Gb of it to back up).

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it running quickly" backup I want, not the same as I have with the
    incremental backups. If the image is bad for some reason then I can
    always fall back to my incremental backups.

    What I do is start by taking a copy of the SD card as an image file on
    to my NAS drive. Where the Pi's are using USB sticks, they are set up
    with with a boot and a root partition, just like an SD card, so the
    image can be updated with the boot partition from the SD card, and the
    root partition from the USB stick.

    Every night I run a cron script to rsync the days changed files from the
    boot and root partitions of each Pi to the corresponding partition of
    the image file on the NAS. That way if any of the machine's storage
    fails, I can immediately write the image on to a new SD card (or USB
    stick) and be back up running in minutes.

    I have other scripts which run monthly to archive the images on to off
    line storage. This runs zerofree on image files to blank any free space
    on them, so they compress better with pigz (parallel gzip, other
    algorithms compress better but take much longer). The archived files are
    named with date, so I can keep several copies and delete them when they
    are too old. I make sure I've got an up to date archive copy before I do
    any system upgrade, so I can go back to the previous version if problems
    only show up after the nightly backup has updated the previous image.

    ---druck
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to druck on Tue Aug 3 15:32:32 2021
    druck <news@druck.org.uk> wrote:
    On 02/08/2021 10:29, Chris Green wrote:
    So, what could I have done to make things quicker/easier?

    My incremental backups are automatic and run every night, when they're
    more than a month old the system weeds some of them out but I have
    monthly backups for some years back now. I'm not aiming to change this.

    However some sort of nightly 'image copy' would make what I had to do
    on Sunday much easier. It has to be automatic (i.e. run by anacron or cron) or it won't get done. This is a headless system so it has to
    be non-GUI too (with the advantage that as it's a "Lite" installation there's only about 1.5Gb of it to back up).

    Is there some sort of "make an image copy of this system" I can run on
    the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it running quickly" backup I want, not the same as I have with the
    incremental backups. If the image is bad for some reason then I can
    always fall back to my incremental backups.

    What I do is start by taking a copy of the SD card as an image file on
    to my NAS drive. Where the Pi's are using USB sticks, they are set up
    with with a boot and a root partition, just like an SD card, so the
    image can be updated with the boot partition from the SD card, and the
    root partition from the USB stick.

    Every night I run a cron script to rsync the days changed files from the
    boot and root partitions of each Pi to the corresponding partition of
    the image file on the NAS. That way if any of the machine's storage
    fails, I can immediately write the image on to a new SD card (or USB
    stick) and be back up running in minutes.

    Yes, I think this sounds a good approach. One can mount the image
    file on the backup system so that it's partitions and files are
    visible so - as you say - you can rsync the changes across.

    It'll take a little configuring and setting up but not a lot and once
    running smoothly I can go back to ignoring it all again! :-)

    Thanks for all the input everyone.

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to Chris Green on Tue Aug 3 19:47:09 2021
    Chris Green <cl@isbd.net> wrote:
    druck <news@druck.org.uk> wrote:
    On 02/08/2021 10:29, Chris Green wrote:
    So, what could I have done to make things quicker/easier?

    My incremental backups are automatic and run every night, when they're more than a month old the system weeds some of them out but I have monthly backups for some years back now. I'm not aiming to change this.

    However some sort of nightly 'image copy' would make what I had to do
    on Sunday much easier. It has to be automatic (i.e. run by anacron or cron) or it won't get done. This is a headless system so it has to
    be non-GUI too (with the advantage that as it's a "Lite" installation there's only about 1.5Gb of it to back up).

    Is there some sort of "make an image copy of this system" I can run on the Pi to write an image to another system? I'd just keep a single
    image I think and overwrite it every night, it's a "restore and get it running quickly" backup I want, not the same as I have with the incremental backups. If the image is bad for some reason then I can always fall back to my incremental backups.

    What I do is start by taking a copy of the SD card as an image file on
    to my NAS drive. Where the Pi's are using USB sticks, they are set up
    with with a boot and a root partition, just like an SD card, so the
    image can be updated with the boot partition from the SD card, and the
    root partition from the USB stick.

    Every night I run a cron script to rsync the days changed files from the boot and root partitions of each Pi to the corresponding partition of
    the image file on the NAS. That way if any of the machine's storage
    fails, I can immediately write the image on to a new SD card (or USB
    stick) and be back up running in minutes.

    Yes, I think this sounds a good approach. One can mount the image
    file on the backup system so that it's partitions and files are

    Oops, "... that its partitions ..." (well it annoys me!)

    visible so - as you say - you can rsync the changes across.

    It'll take a little configuring and setting up but not a lot and once
    running smoothly I can go back to ignoring it all again! :-)

    Thanks for all the input everyone.

    --
    Chris Green
    ·

    --
    Chris Green
    ·
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to druck on Wed Aug 4 10:29:13 2021
    On 03/08/2021 15:02, druck wrote:
    What I do is start by taking a copy of the SD card as an image file on
    to my NAS drive. Where the Pi's are using USB sticks, they are set up
    with with a boot and a root partition, just like an SD card, so the
    image can be updated with the boot partition from the SD card, and the
    root partition from the USB stick.

    Every night I run a cron script to rsync the days changed files from the
    boot and root partitions of each Pi to the corresponding partition of
    the image file on the NAS. That way if any of the machine's storage
    fails, I can immediately write the image on to a new SD card (or USB
    stick) and be back up running in minutes.

    [Snip]

    I make sure I've got an up to date archive copy before I do
    any system upgrade, so I can go back to the previous version if problems
    only show up after the nightly backup has updated the previous image.

    I had to practice what I preached yesterday. I did an upgrade of all 14
    of my active Raspberry Pi's, but had problems with 4 of the Zero W's,
    which wouldn't come back up immediately. I got two of them back up after
    a few reboots, but attaching the other two to a monitor revealed
    networking wouldn't come up. After trying lots of stuff I decided to
    rewrite the card with the previous night's image. This fixed one of the
    Pi's but the other fails to run avahi, wpa-suplicant and dhcpcd, I can
    get only get networking up by manually running dhcpcd.

    I'd say this could be a hardware failure as Wifi is working, it doesn't
    report any Bluetooth devices. Although one of the other ZeroW's which
    didn't come up immediately is also lacking Bluetooth, and the Bluetooth
    driver was one of the things that was updated.

    But anyhow the disaster recovery element worked, being able to
    successfully roll back a suspect update.

    ---druck
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)