OpenWRT and Backing Up: Difference between revisions

(3 intermediate revisions by the same user not shown)

Line 1:

'''SEE THIS ARTICLE INSTEAD: [[OpenWRT and Bare Metal BackUps#Restoring%20a%20BackUp%20from%20an%20Image%20File(s)|OpenWRT and Bare Metal BackUps - Wiki.TerraBase.info]]'''

This article is mostly about doing a bare metal backup of an x86 based OpenWRT system. There are some notes about the additional items that need to be done for a more typical installation on a Router with with Flash based storage (IE, using the

Line 60:

Line 62:

Bad news. The delete command doesn't always work. After issuing the command on a legitimate Loop Device, and with no errors, the Loop Device will persist. Checking it with LOSETUP -a shows it is still there. Accessing it with CFDISK or MOUNT still works. Oh, well. Windows solution time. Reboot.

=== Overlay, OverlayFS, Union Mount, SquashFS, F2FS, and more. ===

===Overlay, OverlayFS, Union Mount, SquashFS, F2FS, and more.===

==== "QuickD" ====

===="QuickD"====

Real quick, here's what's going on with a typical Router based installation of OpenWRT that is stored on Flash Memory Storage.

Line 69:

Line 71:

How is it done? Using the [[wikipedia:OverlayFS|Overlay]] / [[wikipedia:Union_mount|Union Mount]] capabilities of Linux. Sorry, not here to explain that fully, hence the above links.

==== Backing up the /overlay Directory ====

====Backing up the /overlay Directory====

Ideally (since LVM isn't typically available to do "Volume Shadow Copies"), one would boot to an alternative OS, use DD to clone the /overlay "Partition" / "Device". Easy with an x86_64 based install of OpenWRT, but also very possible with a Router based on Flash Memory Storage too. For the Router scenario, again ideally, if the /overlay "Partition" / "Device" is on an external USB Flash Drive (as it should be if a router has a USB 3.0 port), just pop it into a "Linux Box" (virtual or otherwise) for backing up. It can also be done "live" without much chance of something being modified during the cloning process.

* While booted to an alternate OS (Rocky Linux, another OpenWRT install on a USB Flash Drive, etc.), in this example, booted to another OS, but first;

*Make a BackUp: While booted to an alternate OS (Rocky Linux, another OpenWRT install on a USB Flash Drive, etc.), in this example, booted to another OS, do... Wait, but first;

** Locate where the /overlay Partition is;

**Locate where the /overlay Partition is;

*** LSBLK will show ~~where that~~ is

***LSBLK will show the connection between the /overlay Directory and what it is "connected to" (hint for x86 systems, look in the /boot/grub/grub.cfg file)

**** For an OpenWRT install with /overlay on a USB Flash Drive: /overlay will be on /dev/sdXy (where X is a letter and y is a number, example: sda1)

****For an OpenWRT install with /overlay on a USB Flash Drive: /overlay will be on /dev/sdXy (where X is a letter and y is a number, example: sda1)

**** For an OpenWRT install with /overlay on a SATA Disk Drive / SSD: /overlay will be on a [[wikipedia:Loop_device|Loop Device]], roughly equivalent to a VHD or VHDX File where a file represents a storage device

****For an OpenWRT install with /overlay on a SATA Disk Drive / SSD: /overlay will be on a [[wikipedia:Loop_device|Loop Device]], roughly equivalent to a VHD or VHDX File where a file represents a storage device

***** Use this command: losetup -a (it will display something like this: /dev/loop0: (Some Numbers) (/sda2), offset 3014656 (/dev/loop0 is the device and /sda2 is the "file", actually a real drive))

*****Use this command: losetup -a (it will display something like this: /dev/loop0: (Some Numbers) (/sda2), offset 3014656 (/dev/loop0 is the device and /sda2 is the "file", actually a real drive))

****

**"Create" a LOOP Device (For an x86 (used interchangeably with x86_64, yes, yes, don't say it));

***Generic Syntax: losetup -o OffsetInBytes /dev/loopX /WhatEverPath/WhatEverFileName

***OpenWRT specific Syntax: losetup -o 3014656 -fP /WhatEverPath/WhatEverFileName (3014656* is the offset picked by the OpenWRT developers, losetup will pick the next available LOOP#)

***OpenWRT Syntax Example: losetup -o 3014656 -fP /mnt/sda1/OpenWRT_BackUp.img

**Mount the LOOP Device (again for an x86 system)

***Example: mount -t f2fs /dev/loop1 /mnt/loop1 (mkdir /mnt/loop1 before this command of course)

**...and that's it for x86 devices. From there, just cp

~~3014656~~

<nowiki>*</nowiki>If you haven't spotted it yet, but you've been asking, "Where is that file that OpenWRT mounts a Directory named /overlay as a LOOP Device?" Answer: There is no file. It is simply a sector on the Disk / SSD Drive to the end of it. And you might ask, "But won't it be overwritten?" Answer: Nope, because everything before it is considered ROM (as in no write), so it won't expand. And yes that means the entire disk drive (well, at least the OpenWRT partitions) is considered a File that breaks down into a ROM Section and an /overlay Section.

~~losetup -o OFFSET_IN_BYTES /dev/loopX /path~~/to/~~your/file~~

Why 3014656 Bytes as the offset? Well, it works out to 5888 Sectors (512 Bytes / Sector, $1700 (that's Commodore Hexadecimal Notation)), 1472 Sectors (if translated to 2048 Bytes / Sector, $5CO), so nothing really jumps out. If it was the 1980s, there might be some unique point in the CHS format where this makes sense. Some other alignment? Doesn't make any sense with SSDs, but maybe something with HDDs. PI ( π )? Nope, that's 3.141592. Maximum "ROM" size (with room left for expansion)? That seems so much like Bill Gate's comment on 640K should probably be about enough for anyone, when putting important stuff above the top of RAM, thus blocking easy expansion and requiring workarounds.

~~losetup -o 3014656 -fP /mnt/sda1/OpenWRT_SDC2.img~~

mount -t f2fs /dev/loop1 /mnt/loop1

===MBR Gap===

And it seemed like all the backup stuff was done. Nope. There's also a 'hidden' (not on purpose) region in the [[wikipedia:BIOS_boot_partition#Overview|MBR Gap]] that contains [[wikipedia:GNU_GRUB#Version_0_(GRUB_Legacy)|stage 1.5 of the GRUB Boot Loader]]. See this: [[OpenWRT x86 Style Disks and Booting|OpenWRT x86 Style Disks and Booting - Wiki.TerraBase.info]]

===Summary of Everything Backed Up===

*MBR

*MBR Gap

*Boot Partition

*Root Partition

*Overlay "Partition"

===And More...===

What about taking that RAW Image created by DD and turning it into a VHD File (or just about any other virtual disk format)

@@ Line 1: / Line 1: @@
+'''SEE THIS ARTICLE INSTEAD: [[OpenWRT and Bare Metal BackUps#Restoring%20a%20BackUp%20from%20an%20Image%20File(s)|OpenWRT and Bare Metal BackUps - Wiki.TerraBase.info]]'''
 This article is mostly about doing a bare metal backup of an x86 based OpenWRT system.  There are some notes about the additional items that need to be done for a more typical installation on a Router with with Flash based storage (IE, using the
@@ Line 60: / Line 62: @@
 Bad news.  The delete command doesn't always work.  After issuing the command on a legitimate Loop Device, and with no errors, the Loop Device will persist.  Checking it with LOSETUP -a shows it is still there.  Accessing it with CFDISK or MOUNT still works.  Oh, well.  Windows solution time.  Reboot.
-=== Overlay, OverlayFS, Union Mount, SquashFS, F2FS, and more. ===
+===Overlay, OverlayFS, Union Mount, SquashFS, F2FS, and more.===
-==== "QuickD" ====
+===="QuickD"====
 Real quick, here's what's going on with a typical Router based installation of OpenWRT that is stored on Flash Memory Storage.
@@ Line 69: / Line 71: @@
 How is it done?  Using the [[wikipedia:OverlayFS|Overlay]] / [[wikipedia:Union_mount|Union Mount]] capabilities of Linux.  Sorry, not here to explain that fully, hence the above links.
-==== Backing up the /overlay Directory ====
+====Backing up the /overlay Directory====
 Ideally (since LVM isn't typically available to do "Volume Shadow Copies"), one would boot to an alternative OS, use DD to clone the /overlay "Partition" / "Device".  Easy with an x86_64 based install of OpenWRT, but also very possible with a Router based on Flash Memory Storage too.  For the Router scenario, again ideally, if the /overlay "Partition" / "Device" is on an external USB Flash Drive (as it should be if a router has a USB 3.0 port), just pop it into a "Linux Box" (virtual or otherwise) for backing up.  It can also be done "live" without much chance of something being modified during the cloning process.
-* While booted to an alternate OS (Rocky Linux, another OpenWRT install on a USB Flash Drive, etc.), in this example, booted to another OS, but first;
+*Make a BackUp: While booted to an alternate OS (Rocky Linux, another OpenWRT install on a USB Flash Drive, etc.), in this example, booted to another OS, do...  Wait, but first;
-** Locate where the /overlay Partition is;
+**Locate where the /overlay Partition is;
-*** LSBLK will show where that is
+***LSBLK will show the connection between the /overlay Directory and what it is "connected to" (hint for x86 systems, look in the /boot/grub/grub.cfg file)
-**** For an OpenWRT install with /overlay on a USB Flash Drive: /overlay will be on /dev/sdXy (where X is a letter and y is a number, example: sda1)
+****For an OpenWRT install with /overlay on a USB Flash Drive: /overlay will be on /dev/sdXy (where X is a letter and y is a number, example: sda1)
-**** For an OpenWRT install with /overlay on a SATA Disk Drive / SSD: /overlay will be on a [[wikipedia:Loop_device|Loop Device]], roughly equivalent to a VHD or VHDX File where a file represents a storage device
+****For an OpenWRT install with /overlay on a SATA Disk Drive / SSD: /overlay will be on a [[wikipedia:Loop_device|Loop Device]], roughly equivalent to a VHD or VHDX File where a file represents a storage device
-***** Use this command: losetup -a (it will display something like this: /dev/loop0: (Some Numbers) (/sda2), offset 3014656  (/dev/loop0 is the device and /sda2 is the "file", actually a real drive))
+*****Use this command: losetup -a (it will display something like this: /dev/loop0: (Some Numbers) (/sda2), offset 3014656  (/dev/loop0 is the device and /sda2 is the "file", actually a real drive))
-****
+**"Create" a LOOP Device (For an x86 (used interchangeably with x86_64, yes, yes, don't say it));
+***Generic Syntax: losetup -o OffsetInBytes /dev/loopX /WhatEverPath/WhatEverFileName
+***OpenWRT specific Syntax: losetup -o 3014656 -fP /WhatEverPath/WhatEverFileName (3014656* is the offset picked by the OpenWRT developers, losetup will pick the next available LOOP#)
+***OpenWRT Syntax Example: losetup -o 3014656 -fP /mnt/sda1/OpenWRT_BackUp.img
+**Mount the LOOP Device (again for an x86 system)
+***Example: mount -t f2fs /dev/loop1 /mnt/loop1 (mkdir /mnt/loop1 before this command of course)
+**...and that's it for x86 devices.  From there, just cp
-3014656
+<nowiki>*</nowiki>If you haven't spotted it yet, but you've been asking, "Where is that file that OpenWRT mounts a Directory named /overlay as a LOOP Device?"  Answer: There is no file.  It is simply a sector on the Disk / SSD Drive to the end of it.  And you might ask, "But won't it be overwritten?"  Answer: Nope, because everything before it is considered ROM (as in no write), so it won't expand.  And yes that means the entire disk drive (well, at least the OpenWRT partitions) is considered a File that breaks down into a ROM Section and an /overlay Section.
-losetup -o OFFSET_IN_BYTES /dev/loopX /path/to/your/file
+Why 3014656 Bytes as the offset?  Well, it works out to 5888 Sectors (512 Bytes / Sector, $1700 (that's Commodore Hexadecimal Notation)), 1472 Sectors (if translated to 2048 Bytes / Sector, $5CO), so nothing really jumps out.  If it was the 1980s, there might be some unique point in the CHS format where this makes sense.   Some other alignment?  Doesn't make any sense with SSDs, but maybe something with HDDs.  PI ( π )?  Nope, that's 3.141592.  Maximum "ROM" size (with room left for expansion)?  That seems so much like Bill Gate's comment on 640K should probably be about enough for anyone, when putting important stuff above the top of RAM, thus blocking easy expansion and requiring workarounds.
-losetup -o 3014656 -fP /mnt/sda1/OpenWRT_SDC2.img
 mount -t f2fs /dev/loop1 /mnt/loop1
+===MBR Gap===
+And it seemed like all the backup stuff was done.  Nope.  There's also a 'hidden' (not on purpose) region in the [[wikipedia:BIOS_boot_partition#Overview|MBR Gap]] that contains [[wikipedia:GNU_GRUB#Version_0_(GRUB_Legacy)|stage 1.5 of the GRUB Boot Loader]].  See this: [[OpenWRT x86 Style Disks and Booting|OpenWRT x86 Style Disks and Booting - Wiki.TerraBase.info]]
+===Summary of Everything Backed Up===
+*MBR
+*MBR Gap
+*Boot Partition
+*Root Partition
+*Overlay "Partition"
 ===And More...===
 What about taking that RAW Image created by DD and turning it into a VHD File (or just about any other virtual disk format)