Alpine local backup: Difference between revisions

From Alpine Linux
(replaced category: LBU by category: Diskless as diskless is more generic)
 
(97 intermediate revisions by 10 users not shown)
Line 1: Line 1:
When Alpine Linux boots in diskless mode, initially it only loads a few required packages from the boot device by default.
When Alpine Linux boots in diskless mode, it initially only loads a few required packages from the boot device.
But local adjustments in RAM are possible, e.g. by [[Alpine_package_management|installing a package]] or adjusting some configuration.


And all the modifications can be saved to an overlay file (.apkovl) to make them survive a reboot.
However, local adjustments to what-gets-loaded-into-RAM are possible, e.g. by [[Alpine_Package_Keeper|installing a package]] or adjusting the configuration files in {{path|/etc}}. The modifications can be saved to an overlay file (.apkovl) that can be automatically loaded when booting, to restore the saved state.
 
The .apkovl file that contains the custom configuration can be saved to writable storage with Alpine's local backup utility <code>lbu</code>. By configuring a [[Alpine_Linux_package_management#Local_Cache|local package cache]] the additional packages the configuration depends on, can also be kept available on local, writable storage.
 
{{Note|If you installed Alpine in "sys" disk mode, you don't need to use <code>lbu</code> to save the system state. With a system disk, all modifications are
written directly to disk. Nevertheless, <code>lbu</code> can be useful for some maintenance tasks.}}


This is what the local backup utility <code>lbu</code> together with a [[Alpine_Linux_package_management#Local_Cache|local package cache]] is good for!


__TOC__
__TOC__


{{Note|If you installed Alpine on HDD you don't need to use <code>lbu</code>, because in this case all modifications are directly written to HDD. However, <code>lbu</code> may still be useful for some maintenance tasks.}}


The first thing you need to know is this: '''By default <code>lbu</code> only cares about modifications in {{Path|/etc}} and its subfolders, with the exception of {{Path|/etc/init.d}}!''' <BR>
{{Warning|
Please have a look at [[#Include_special_files.2Ffolders_to_the_apkovl|lbu include]] to save files/folders located elsewhere than in {{Path|/etc}}.
'''By default, an <code>lbu commit</code> only stores modifications below {{Path|/etc}}''', with the exception of the {{Path|/etc/init.d/}} directory.
 
If a user was created during the <code>setup-alpine</code> script, that user's home directory is also added to the paths that <code>lbu</code> will backup up.
 
However, [[#Include_special_files.2Ffolders_to_the_apkovl|lbu include]] enables modifying that set of included files, and can be used to specify additional files or folders.
}}
 
 
== Saving and loading ISO image customizations ==
{{Main|Diskless Mode}}
 
== Committing changes ==


Alpine has the following tools for permanently storing your modifications:
The <code>lbu</code> tool has several subcommands to manage the .apkovl:
* lbu
* lbu
* lbu commit ''(Same as 'lbu ci')''
* lbu commit ''(Same as 'lbu ci')''
Line 25: Line 38:
* lbu revert
* lbu revert


In the below examples you will find some characters with special meaning:
In the examples below, you will find some characters with special meaning:
* '''|''' = '''or''' ''('lbu commit|ci' means that you can type ether 'lbu commit' or 'lbu ci')''
* '''|''' = '''or''' ''('lbu commit|ci' means that you can type ether 'lbu commit' or 'lbu ci')''
* '''[ ]''' = '''optional''' ''(In 'lbu commit|ci [-nv]' you can just skip the '-n', '-v' or '-nv' part if you don't want it)''
* '''[ ]''' = '''optional''' ''(In 'lbu commit|ci [-nv]' you can skip the '-n', '-v' or '-nv' part if you don't want it)''


== Committing your changes ==


=== Basic Command ===
=== Basic "commit" command ===
When you "commit" or save changes you've made to your system, <code>lbu</code> will generate a file named something like {{Path|<var>myboxname</var>.apkovl.tar.gz}} ''('myboxname' will be the same as the hostname)''.
When you "commit" or save changes you've made to your system, <code>lbu</code> will generate a file named something like {{Path|<var>myboxname</var>.apkovl.tar.gz}} ''('myboxname' will be the same as the hostname)''.
This file (that contains your modifications) is called your "apkovl".
The file (which contains your modifications) is called your "apkovl".
You will need to save your apkovl on some suitable media (floppy, usb, cf, other).
You will need to save your apkovl on suitable media (floppy, usb, cf, etc.).
<pre>
<pre>
usage: lbu commit|ci [-nv] [<media>]
usage: lbu commit|ci [-nv] [<media>]
Line 45: Line 57:
   -v Verbose mode.
   -v Verbose mode.


The following values for <media> is supported: floppy usb
The following values for <media> are supported: floppy usb
If <media> is not specified, the environment variable LBU_MEDIA will be used.
If <media> is not specified, the environment variable LBU_MEDIA will be used.


Line 52: Line 64:
For possible ciphers, try: openssl -v
For possible ciphers, try: openssl -v


The password used to encrypt the file, can either be specified with the -p
The password used to encrypt the file, can be specified with the -p
option or using the PASSWORD environment variable.
option or by using the PASSWORD environment variable.


The environment variables can also be set in /etc/lbu/lbu.conf
The environment variable can also be set in /etc/lbu/lbu.conf
</pre>
</pre>


=== Saving and loading ISO image customizations ===
=== Creating an .apkovl "package" elsewhere than on the configured media ===
 
Besides supporting a boot parameter to load customizations from a web server, the "diskless mode" Alpine ISO images also look for an .apkovl volume in system partitions, and and allow to save the local backups and the package cache to mountpoints below /media/, if they exist. It currently requires to proceed as follows:
 
# Boot the diskless system from ISO, and if necessary create and format a partition.
# Edit /etc/fstab and mount the writable partition to /media/sda1 (if sda1 is your writable partition).
# Run setup-alpine and choose to save configs and package cache to the mounted partition.
# Customize the system.
# Generate an APKOVL file with [[Alpine_local_backup|lbu]] by executing <code>lbu commit</code>
 
Notes:


* If the partition resides on a fixed device (i.e. not in an automatically created mountpoint under /media) it is currently needed to specify kernel boot parameters. (See [[PXE_boot#Specifying_an_apkovl]].)
To "commit" changes, but override the destination of the generated apkovl file, use <code>lbu package</code> instead of <code>lbu commit</code>:
* For a virtual machine, the '''[[Qemu#Live_mode|Qemu example]]''' shows how an ISO image can automatically boot with .apkovl customizations.
* [[Alpine_Linux_package_management#Local_Cache]] covers managing included packages.
* [[Alpine_local_backup|lbu]] explains how to include customized files outside of <code>/etc</code>.
* All packages listed in /etc/apk/world of the lbu will be automatically installed when the live system boots.
* It's possible to load an APKOVL file from a webserver, by supplying a custom url with the <code>APKOVL</code> kernel boot parameter.
* If you don't have a web server you can run busybox's httpd temporarily to serve an .apkovl - <code>busybox httpd -p 127.0.0.1:80</code>.
 
=== Create a apkovl elsewhere than on your configured media ===
 
To "commit" changes, but overriding the destination of the generated apkovl file, use <code>lbu package</code> instead of <code>lbu commit</code>:


<pre>
<pre>
Line 95: Line 87:


If neither <dirname> nor <filename> is specified, a package named
If neither <dirname> nor <filename> is specified, a package named
<hostname>.apkovl.tar.gz will be created in current work directory.
<hostname>.apkovl.tar.gz will be created in the current working directory.
</pre>
</pre>


=== Use SSH to create an apkovl on a different host ===
=== Creating and saving an apkovl from a remote host ===


To create an apkovl of client on a centralized server, use <code>lbu package</code> with {{Path|-}} as the apkovl name:
To create an apkovl from a client on a remote server, it's possible to use <code>lbu package</code> via SSH with {{Path|-}} as the apkovl name:


On the server:
On the server:
Line 107: Line 99:
</pre>
</pre>


== Check what will be added to your apkovl ==
== Checking what will be added to your apkovl ==


<code>lbu status</code> lists what will be saved the next time you run <code>lbu commit</code>. Its default output is incremental, that is, to only show what files have changed since the last commit; but this can be overridden with the <code>-a</code> flag:
<code>lbu status</code> lists what will be saved the next time you run <code>lbu commit</code>. Its default output is incremental, that is, it shows
only the files that have changed since the last commit. <br>
This can be overridden with the <code>-a</code> flag:


<pre>
<pre>
Line 116: Line 110:
Options:
Options:
   -a    Compare all files, not just since last commit.
   -a    Compare all files, not just since last commit.
   -v    Also show include and exclude lists.
   -v    show include and exclude lists.
</pre>
</pre>


Line 126: Line 120:


   usage: lbu diff
   usage: lbu diff


== Include special files/folders to the apkovl ==
== Include special files/folders to the apkovl ==
Assume that you have some files that you want to permanently save, but they are located somewhere else than in {{Path|/etc}}.<BR>
Assume you have some files you want to save permanently, but they are not located in {{Path|/etc}}.<BR>
It could be {{Path|/root/.ssh/authorized_keys}} (used by <code>sshd</code> to authenticate ssh-users). Such files/folders can be added to lbu's ''include'' list with the following command:
e.g. {{Path|/root/.ssh/authorized_keys}} (used by <code>sshd</code> to authenticate ssh-users). Such files/folders can be added to lbu's ''include'' list with the following command:


<pre>
<pre>
Line 138: Line 131:
Options:
Options:
   -l List contents of include list.
   -l List contents of include list.
   -r Remove specified file(s) from include list instead of adding.
   -r Remove specified file(s) from include list.
   -v Verbose mode.
   -v Verbose mode.
</pre>
</pre>


{{Note|This information used to be maintained in {{Path|/etc/lbu/include}}; now it's instead maintained together with the ''exclude'' list in {{Path|/etc/apk/protected_paths.d/lbu.list}}. Either way, the command <code>lbu include</code> only modifies lbu's configuration; you will need to run <code>lbu commit</code> to actually create/modify your apkovl.}}
{{Note|This information used to be maintained in {{Path|/etc/lbu/include}}. Now it's maintained together with the ''exclude'' list in {{Path|/etc/apk/protected_paths.d/lbu.list}}. Either way, the command <code>lbu include</code> only modifies lbu's configuration.
You will need to run <code>lbu commit</code> to actually create/modify your apkovl.}}






== Exclude specific files/folders from the apkovl ==
== Exclude specific files/folders from the apkovl ==
Assume that you have some files located in {{Path|/etc}} or one of its subfolders that you ''do not'' want to permanently save.
Assume you have some files located in {{Path|/etc}} or one of its subfolders you ''do not'' want to save.
It could be some log file or status file that for some reason isn't in {{Path|/var/log/}} but in some location that would otherwise be tracked by <code>lbu</code>.
It could be a log file or status file that for some reason isn't in {{Path|/var/log/}} but in a location that would otherwise be tracked by <code>lbu</code>.
Such files/folders can be added to lbu's ''exclude'' list by manually editing that file or using the following command:
Such files/folders can be added to lbu's ''exclude'' list by manually editing the file or using the following command:
<pre>
<pre>
usage: lbu exclude|ex|delete [-rv] <file> ...
usage: lbu exclude|ex|delete [-rv] <file> ...
Line 156: Line 150:
Options:
Options:
   -l List contents of exclude list.
   -l List contents of exclude list.
   -r Remove specified file(s) from exclude list instead of adding.
   -r Remove specified file(s) from exclude list.
   -v Verbose mode.
   -v Verbose mode.
</pre>
</pre>
{{Note|As stated above, this information is now maintained in {{Path|/etc/apk/protected_paths.d/lbu.list}}. The command <code>lbu exclude</code> also only modifies lbu's configuration; you will need to run <code>lbu commit</code> to actually create/modify your apkovl.}}
{{Note|As stated above, this information is now maintained in {{Path|/etc/apk/protected_paths.d/lbu.list}}. The command <code>lbu exclude</code> also only modifies lbu's configuration. <br>
You will need to run <code>lbu commit</code> to actually create/modify your apkovl.}}




Line 165: Line 160:
== Execute a script as part of a backup ==
== Execute a script as part of a backup ==


Sometimes it is necessary to run a script before or after a backup.  Scripts in two optional directories allow for this:
Sometimes it's necessary to run a script before or after a backup.  Scripts in two optional directories enable that:


  /etc/lbu/pre-package.d
  /etc/lbu/pre-package.d
  /etc/lbu/post-package.d
  /etc/lbu/post-package.d


Files in those directories are run using run-script rules (meaning they must have the executable bit set, they are run in alphabetical order, and cannot contain an extension: {{Path|runme}} works, but {{Path|runme.sh}} does not.)
Files in those directories are run using run-script rules (meaning they must have the executable bit set, they are run in alphabetical order, and cannot contain an extension. e.g. {{Path|runme}} works, but {{Path|runme.sh}} does not. Also the shebang line on the first line should be indicated, e.g. #!/bin/sh .)


The scripts in {{Path|pre-package.d}} are run before the apkovl is created; scripts in {{Path|post-package.d}} are run after the apkovl is created.
The scripts in {{Path|pre-package.d}} are run before apkovl is created. Scripts in {{Path|post-package.d}} are run after apkovl is created.


=== Example ===
=== Example ===


Rather than adding the raw database directories to {{Path|/etc/lbu/include}}, you can do a "database dump".    For purposes of example, we use {{Pkg|postgresql}}:
Rather than adding the raw database directories to {{Path|/etc/lbu/include}}, you can do a "database dump".    e.g. {{Pkg|postgresql}}:


* Create {{Path|/etc/lbu/pre-package.d/sqldump}} with the following contents: <pre>pg_dumpall -U postgres | gzip -c >/root/pgdatabases.gz</pre>
* Create {{Path|/etc/lbu/pre-package.d/sqldump}} with the following contents: <pre>pg_dumpall -U postgres | gzip -c >/root/pgdatabases.gz</pre>
Line 184: Line 179:
* Finally, add the database dump file to the list of files to back up: <code>lbu include root/pgdatabases.gz</code>
* Finally, add the database dump file to the list of files to back up: <code>lbu include root/pgdatabases.gz</code>


Now whenever you do a <code>lbu commit</code>, the sql databases are dumped and gzipped to {{Path|/root/pgdatabases.gz}}, and then the temporary file is deleted at the end of the lbu commit.
Now when you do a <code>lbu commit</code>, the sql databases are dumped and gzipped to {{Path|/root/pgdatabases.gz}}.
The temporary file is deleted at the end of the lbu commit.


On a catastrophic restore, the databases are not automatically restored (that's not lbu's responsibility), but you will find a complete database dump in the {{Path|/root}} directory, where it can be restored manually.
On a catastrophic restore, the databases are not automatically restored (that's not lbu's job), but you will find a complete database dump in the {{Path|/root}} directory, where it can be restored manually.




P.s. These scripts are also launched when starting the commands: diff, list-backup, package, revert, status.


== Multiple Backups ==
== Multiple backup versions ==
Lbu can now keep backups so you can revert to older, good known config.
Lbu can now keep multiple backups so you can revert back to older configurations.
Set BACKUP_LIMIT in {{Path|/etc/lbu/lbu.conf}} to the number of backups you want
Set BACKUP_LIMIT in {{Path|/etc/lbu/lbu.conf}} to the number of backups you want
to keep.
to keep.


You can list the current backups with:
If you've set BACKUP_LIMIT, then the previously active .apkovl will be renamed before creating the new file.
 
You can list the currently available backups with:


{{Cmd|lbu list-backup [<media>]}}
{{Cmd|lbu list-backup [<media>]}}


and you can revert to an older with:
and you can revert to an older one with:


{{Cmd|lbu revert <filename> [<media>]}}
{{Cmd|lbu revert <filename> [<media>]}}


Nothing is written to your main system when "reverting"; this only affects which apkovl is considered active. If you've set BACKUP_LIMIT, then the previously active apkovl will be backed up before being overwritten.
NOTE: Nothing is changed on your running system when "reverting", it only affects which apkovl is considered active at the next boot.


== See also ==
== See also ==
Line 213: Line 212:
[[Category:Booting]]
[[Category:Booting]]
[[Category:Package Manager]]
[[Category:Package Manager]]
[[category: LBU]]
[[category: Diskless]]

Latest revision as of 07:05, 6 November 2024

When Alpine Linux boots in diskless mode, it initially only loads a few required packages from the boot device.

However, local adjustments to what-gets-loaded-into-RAM are possible, e.g. by installing a package or adjusting the configuration files in /etc. The modifications can be saved to an overlay file (.apkovl) that can be automatically loaded when booting, to restore the saved state.

The .apkovl file that contains the custom configuration can be saved to writable storage with Alpine's local backup utility lbu. By configuring a local package cache the additional packages the configuration depends on, can also be kept available on local, writable storage.

Note: If you installed Alpine in "sys" disk mode, you don't need to use lbu to save the system state. With a system disk, all modifications are written directly to disk. Nevertheless, lbu can be useful for some maintenance tasks.



Warning:

By default, an lbu commit only stores modifications below /etc, with the exception of the /etc/init.d/ directory.

If a user was created during the setup-alpine script, that user's home directory is also added to the paths that lbu will backup up.

However, lbu include enables modifying that set of included files, and can be used to specify additional files or folders.



Saving and loading ISO image customizations

Committing changes

The lbu tool has several subcommands to manage the .apkovl:

  • lbu
  • lbu commit (Same as 'lbu ci')
  • lbu package (Same as 'lbu pkg')
  • lbu status (Same as 'lbu st')
  • lbu list (Same as 'lbu ls')
  • lbu diff
  • lbu include (Same as 'lbu inc' or 'lbu add')
  • lbu exclude (Same as 'lbu ex' or 'lbu delete')
  • lbu list-backup (Same as 'lbu lb')
  • lbu revert

In the examples below, you will find some characters with special meaning:

  • | = or ('lbu commit|ci' means that you can type ether 'lbu commit' or 'lbu ci')
  • [ ] = optional (In 'lbu commit|ci [-nv]' you can skip the '-n', '-v' or '-nv' part if you don't want it)


Basic "commit" command

When you "commit" or save changes you've made to your system, lbu will generate a file named something like myboxname.apkovl.tar.gz ('myboxname' will be the same as the hostname). The file (which contains your modifications) is called your "apkovl". You will need to save your apkovl on suitable media (floppy, usb, cf, etc.).

usage: lbu commit|ci [-nv] [<media>]

Options:
  -d	Remove old apk overlay files.
  -e	Protect configuration with a password.
  -n	Don't commit, just show what would have been committed.
  -p <password>	Give encryption password on the command-line
  -v	Verbose mode.

The following values for <media> are supported: floppy usb
If <media> is not specified, the environment variable LBU_MEDIA will be used.

Password protection will use aes-256-cbc encryption. Other ciphers can be
used by setting the DEFAULT_CIPHER or ENCRYPTION environment variables.
For possible ciphers, try: openssl -v

The password used to encrypt the file, can be specified with the -p
option or by using the PASSWORD environment variable.

The environment variable can also be set in /etc/lbu/lbu.conf

Creating an .apkovl "package" elsewhere than on the configured media

To "commit" changes, but override the destination of the generated apkovl file, use lbu package instead of lbu commit:

usage: lbu package|pkg -v [<dirname>|<filename>]

Options:
  -v   Verbose mode.

If <dirname> is a directory, a package named <hostname>.apkovl.tar.gz will
be created in the specified directory.

If <filename> is specified, and is not a directory, a package with the
specified name will be created.

If neither <dirname> nor <filename> is specified, a package named
<hostname>.apkovl.tar.gz will be created in the current working directory.

Creating and saving an apkovl from a remote host

To create an apkovl from a client on a remote server, it's possible to use lbu package via SSH with - as the apkovl name:

On the server:

ssh root@client "lbu package -" >client.apkovl.tar.gz

Checking what will be added to your apkovl

lbu status lists what will be saved the next time you run lbu commit. Its default output is incremental, that is, it shows only the files that have changed since the last commit.
This can be overridden with the -a flag:

usage: lbu status|st [-av]

Options:
  -a    Compare all files, not just since last commit.
  -v    show include and exclude lists.

Another option is lbu list. This works like lbu status -a but the format of the output is a bit different. (It's strictly equivalent to lbu package -v /dev/null).

usage: lbu list|ls

A third option is lbu diff. This shows the same incremental changes that lbu status (without -a) does, but in a different format.

 usage: lbu diff

Include special files/folders to the apkovl

Assume you have some files you want to save permanently, but they are not located in /etc.
e.g. /root/.ssh/authorized_keys (used by sshd to authenticate ssh-users). Such files/folders can be added to lbu's include list with the following command:

usage: lbu include|inc|add [-rv] <file> ...
       lbu include|inc|add [-v] -l

Options:
  -l	List contents of include list.
  -r	Remove specified file(s) from include list.
  -v	Verbose mode.
Note: This information used to be maintained in /etc/lbu/include. Now it's maintained together with the exclude list in /etc/apk/protected_paths.d/lbu.list. Either way, the command lbu include only modifies lbu's configuration. You will need to run lbu commit to actually create/modify your apkovl.


Exclude specific files/folders from the apkovl

Assume you have some files located in /etc or one of its subfolders you do not want to save. It could be a log file or status file that for some reason isn't in /var/log/ but in a location that would otherwise be tracked by lbu. Such files/folders can be added to lbu's exclude list by manually editing the file or using the following command:

usage: lbu exclude|ex|delete [-rv] <file> ...
       lbu exclude|ex|delete [-v] -l

Options:
  -l	List contents of exclude list.
  -r	Remove specified file(s) from exclude list.
  -v	Verbose mode.
Note: As stated above, this information is now maintained in /etc/apk/protected_paths.d/lbu.list. The command lbu exclude also only modifies lbu's configuration.
You will need to run lbu commit to actually create/modify your apkovl.


Execute a script as part of a backup

Sometimes it's necessary to run a script before or after a backup. Scripts in two optional directories enable that:

/etc/lbu/pre-package.d
/etc/lbu/post-package.d

Files in those directories are run using run-script rules (meaning they must have the executable bit set, they are run in alphabetical order, and cannot contain an extension. e.g. runme works, but runme.sh does not. Also the shebang line on the first line should be indicated, e.g. #!/bin/sh .)

The scripts in pre-package.d are run before apkovl is created. Scripts in post-package.d are run after apkovl is created.

Example

Rather than adding the raw database directories to /etc/lbu/include, you can do a "database dump". e.g. postgresql:

  • Create /etc/lbu/pre-package.d/sqldump with the following contents:
    pg_dumpall -U postgres | gzip -c >/root/pgdatabases.gz
  • Mark the file executable: chmod +x /etc/lbu/pre-package.d/sqldump
  • Create /etc/lbu/post-package.d/sqldumpdelete with the following contents:
    rm -f /root/pgdatabases.gz
  • Mark the file executable: chmod +x /etc/lbu/post-package.d/sqldumpdelete
  • Finally, add the database dump file to the list of files to back up: lbu include root/pgdatabases.gz

Now when you do a lbu commit, the sql databases are dumped and gzipped to /root/pgdatabases.gz. The temporary file is deleted at the end of the lbu commit.

On a catastrophic restore, the databases are not automatically restored (that's not lbu's job), but you will find a complete database dump in the /root directory, where it can be restored manually.


P.s. These scripts are also launched when starting the commands: diff, list-backup, package, revert, status.

Multiple backup versions

Lbu can now keep multiple backups so you can revert back to older configurations. Set BACKUP_LIMIT in /etc/lbu/lbu.conf to the number of backups you want to keep.

If you've set BACKUP_LIMIT, then the previously active .apkovl will be renamed before creating the new file.

You can list the currently available backups with:

lbu list-backup [<media>]

and you can revert to an older one with:

lbu revert <filename> [<media>]

NOTE: Nothing is changed on your running system when "reverting", it only affects which apkovl is considered active at the next boot.

See also