Alpine local backup: Difference between revisions
m (→Saving and loading ISO image customizations: Remove a whole bunch of underscores.) |
|||
(23 intermediate revisions by 8 users not shown) | |||
Line 1: | Line 1: | ||
When Alpine Linux boots in diskless mode, it initially only loads a few required packages from the boot device. | When Alpine Linux boots in diskless mode, it initially only loads a few required packages from the boot device. | ||
However, local adjustments | 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>. | 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 state | {{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.}} | |||
Line 14: | Line 15: | ||
'''By default, an <code>lbu commit</code> only stores modifications below {{Path|/etc}}''', with the exception of the {{Path|/etc/init.d/}} directory. | '''By default, an <code>lbu commit</code> only stores modifications below {{Path|/etc}}''', with the exception of the {{Path|/etc/init.d/}} directory. | ||
However, | 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. | |||
}} | }} | ||
Line 20: | Line 23: | ||
== Saving and loading ISO image customizations == | == Saving and loading ISO image customizations == | ||
Besides supporting a boot parameter to load customizations from a web server, Alpine's "diskless mode" ISO images | Besides supporting a boot parameter to load customizations from a web server, Alpine's "diskless mode" ISO images try to load an .apkovl volume from system partitions. It is therefore possible to save customized running states to a .apkovl file on a writable partition, and have these automatically loaded when booting the ISO image. | ||
{{Note|When the machine reboots, the remote repositories will not be available until after networking has started. That means packages newer than on your local boot media would not be available after a reboot, unless they were made to persistent, by having a [[#Local Cache|local package cache]] available on a local, writable, storage device.}} | |||
1. Boot the diskless system from ISO<br> | The local package cache, which enables additional and updated packages to automatically be copied into RAM during boot, may be stored on the same partition as the .apkovl file. | ||
2. If necessary, create and format a partition as in [[Setting_up_disks_manually#For_.22diskless.22_and_.22data.22_disk_mode_installs_2]]. For the examples we will use /dev/sdXY<br> | |||
* Bug: [https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/5 Initramfs-init does not respect apkovl device fstab entry], so the partition can not be mounted to /boot | To use partitions on '''internal disks''', however, you need to prepare a specific /etc/fstab entry manually, and save the configuration, as follows (setup-alpine does not list them for saving configs or package cache): | ||
=> Alternative: Configure the /etc/fstab to mount the writable partition to /media/sdXY instead /boot (i.e. conforming to the hot/cold-plug mountpoints):<br> | |||
1. Boot the diskless system from ISO (as shown at [[Installation]])<br> | |||
2. If necessary, create and format a partition as explained in [[Setting_up_disks_manually#For_.22diskless.22_and_.22data.22_disk_mode_installs_2|"Setting up disks manually, for diskless and data disk mode installs"]]. For the examples we will use /dev/sdXY<br> | |||
* Bug: [https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/5 Initramfs-init does not respect apkovl device fstab entry], so the partition can not be mounted to /boot. The workaround given there does not seem to work (e.g. <code>mkdir -p /boot/ovl_dev/cache ; touch /boot/ovl_dev/cache/.boot_repository</code>)<br> | |||
=> Alternative: Configure the /etc/fstab to mount the writable partition to /media/sdXY instead of /boot (i.e. conforming to the hot/cold-plug mountpoints):<br> | |||
3. <code>mkdir /media/sdXY</code><br> | 3. <code>mkdir /media/sdXY</code><br> | ||
4. <code>echo "/dev/sdXY /media/sdXY ext4 noatime,ro 0 0" >> /etc/fstab</code><br> | 4. <code>echo "/dev/sdXY /media/sdXY ext4 noatime,ro 0 0" >> /etc/fstab</code><br> (Mounting read-only is possible, because the tools temporarily remount it writable for their operation.)<br> | ||
5. <code>mount -a</code><br> | 5. Use <code>mount -a</code> to load the partitions listed in /etc/fstab. Look at the output of <code>mount</code> to verify that the /etc/fstab changes have been applied correctly.<br> | ||
6. | 6. If setup-alpine has not run before, it may be used and should now enable you to choose the partition for saving the local configs and package cache. (If asked, there is no need to first unmount the partition, that would only be needed to allow installing on its parent disk.)<br> | ||
If setup-alpine has already been used to configure the diskless system, | If setup-alpine has already been used to configure the diskless system, the storage settings may be modified directly with <code>setup-lbu sdXY</code> and <code>mkdir /media/sdXY/cache ; setup-apkcache /media/sdXY/cache</code><br> | ||
7. If the partition is large enough, it can be useful to edit lbu.conf to uncomment and set <code>BACKUP_LIMIT=3</code> | 7. If the partition is large enough, it can be useful to edit lbu.conf to uncomment and set <code>BACKUP_LIMIT=3</code>. For example, to allow reverting to a previous, working state if needed. | ||
{{cmd| # apk add nano | {{cmd| # apk add nano | ||
# nano /etc/lbu/lbu.conf | # nano /etc/lbu/lbu.conf | ||
}} | }} | ||
8. Finally, generate the first .apkovl file containing all the previous changes | 8. Finally, generate the first .apkovl file containing all the previous changes by executing <code>lbu commit</code>, so the customizations that were just made will persist a reboot. | ||
From then on, whenever packages are installed or newly configured, and the changes should be kept, execute <code>lbu commit</code> again. | |||
Notes: | Notes: | ||
* For a virtual machine, the '''[[ | * For a virtual machine, the '''[[QEMU#Live_mode|QEMU example]]''' shows how an ISO image can automatically boot with .apkovl customizations. | ||
* [ | * The [[Alpine local backup#Include special files.2Ffolders to the apkovl|Include special files section]] explains how to include custom files outside of <code>/etc</code> in the .apkovl file. | ||
* [[ | * [[Alpine Linux package management#Local Cache]] covers managing a local package cache. | ||
* | ** The packages get listed in {{path|/etc/apk/world}} which gets saved with the lbu, for them to 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. | * 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>. | ** 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>. | ||
* To customize the boot sequence further, one may refer to [[ | * To customize the boot sequence further, one may refer to [[PXE boot#Specifying an apkovl]] and [[How to make a custom ISO image with mkimage]]. | ||
== Committing changes == | == Committing changes == | ||
The <code>lbu</code> tool | 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 65: | Line 72: | ||
* lbu revert | * lbu revert | ||
In the below | 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 | * '''[ ]''' = '''optional''' ''(In 'lbu commit|ci [-nv]' you can skip the '-n', '-v' or '-nv' part if you don't want it)'' | ||
=== Basic "commit" 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)''. | ||
The file (which contains your modifications) is called your "apkovl". | |||
You will need to save your apkovl on | 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 84: | Line 91: | ||
-v Verbose mode. | -v Verbose mode. | ||
The following values for <media> | 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 91: | Line 98: | ||
For possible ciphers, try: openssl -v | For possible ciphers, try: openssl -v | ||
The password used to encrypt the file, can | 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 | The environment variable can also be set in /etc/lbu/lbu.conf | ||
</pre> | </pre> | ||
=== Creating an .apkovl "package" elsewhere than on the configured media === | === Creating an .apkovl "package" elsewhere than on the configured media === | ||
To "commit" changes, but | To "commit" changes, but override the destination of the generated apkovl file, use <code>lbu package</code> instead of <code>lbu commit</code>: | ||
<pre> | <pre> | ||
Line 116: | Line 121: | ||
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 | <hostname>.apkovl.tar.gz will be created in the current working directory. | ||
</pre> | </pre> | ||
=== Creating and saving an apkovl from a remote host === | === Creating and saving an apkovl from a remote host === | ||
To create an apkovl from a client on a | 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 130: | Line 135: | ||
== Checking 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, | <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 137: | Line 144: | ||
Options: | Options: | ||
-a Compare all files, not just since last commit. | -a Compare all files, not just since last commit. | ||
-v | -v show include and exclude lists. | ||
</pre> | </pre> | ||
Line 149: | Line 156: | ||
== Include special files/folders to the apkovl == | == Include special files/folders to the apkovl == | ||
Assume | Assume you have some files you want to save permanently, but they are not located in {{Path|/etc}}.<BR> | ||
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 158: | Line 165: | ||
Options: | Options: | ||
-l List contents of include list. | -l List contents of include list. | ||
-r Remove specified file(s) from include list | -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}} | {{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 | Assume you have some files located in {{Path|/etc}} or one of its subfolders you ''do not'' want to save. | ||
It could be | 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 | 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 176: | Line 184: | ||
Options: | Options: | ||
-l List contents of exclude list. | -l List contents of exclude list. | ||
-r Remove specified file(s) from exclude list | -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 | {{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 185: | Line 194: | ||
== Execute a script as part of a backup == | == Execute a script as part of a backup == | ||
Sometimes it | 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 | 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 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". | 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 204: | Line 213: | ||
* 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 | 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 | 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 backup versions == | == Multiple backup versions == | ||
Lbu can now keep multiple backups so you can revert back to older | 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. | ||
Line 225: | Line 236: | ||
{{Cmd|lbu revert <filename> [<media>]}} | {{Cmd|lbu revert <filename> [<media>]}} | ||
NOTE: Nothing is changed on your running system when "reverting", it only affects which apkovl is considered active | 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 == |
Latest revision as of 08:29, 12 January 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.
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.
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
Besides supporting a boot parameter to load customizations from a web server, Alpine's "diskless mode" ISO images try to load an .apkovl volume from system partitions. It is therefore possible to save customized running states to a .apkovl file on a writable partition, and have these automatically loaded when booting the ISO image.
The local package cache, which enables additional and updated packages to automatically be copied into RAM during boot, may be stored on the same partition as the .apkovl file.
To use partitions on internal disks, however, you need to prepare a specific /etc/fstab entry manually, and save the configuration, as follows (setup-alpine does not list them for saving configs or package cache):
1. Boot the diskless system from ISO (as shown at Installation)
2. If necessary, create and format a partition as explained in "Setting up disks manually, for diskless and data disk mode installs". For the examples we will use /dev/sdXY
- Bug: Initramfs-init does not respect apkovl device fstab entry, so the partition can not be mounted to /boot. The workaround given there does not seem to work (e.g.
mkdir -p /boot/ovl_dev/cache ; touch /boot/ovl_dev/cache/.boot_repository
)
=> Alternative: Configure the /etc/fstab to mount the writable partition to /media/sdXY instead of /boot (i.e. conforming to the hot/cold-plug mountpoints):
3. mkdir /media/sdXY
4. echo "/dev/sdXY /media/sdXY ext4 noatime,ro 0 0" >> /etc/fstab
(Mounting read-only is possible, because the tools temporarily remount it writable for their operation.)
5. Use mount -a
to load the partitions listed in /etc/fstab. Look at the output of mount
to verify that the /etc/fstab changes have been applied correctly.
6. If setup-alpine has not run before, it may be used and should now enable you to choose the partition for saving the local configs and package cache. (If asked, there is no need to first unmount the partition, that would only be needed to allow installing on its parent disk.)
If setup-alpine has already been used to configure the diskless system, the storage settings may be modified directly with setup-lbu sdXY
and mkdir /media/sdXY/cache ; setup-apkcache /media/sdXY/cache
7. If the partition is large enough, it can be useful to edit lbu.conf to uncomment and set BACKUP_LIMIT=3
. For example, to allow reverting to a previous, working state if needed.
# apk add nano # nano /etc/lbu/lbu.conf
8. Finally, generate the first .apkovl file containing all the previous changes by executing lbu commit
, so the customizations that were just made will persist a reboot.
From then on, whenever packages are installed or newly configured, and the changes should be kept, execute lbu commit
again.
Notes:
- For a virtual machine, the QEMU example shows how an ISO image can automatically boot with .apkovl customizations.
- The Include special files section explains how to include custom files outside of
/etc
in the .apkovl file. - Alpine Linux package management#Local Cache covers managing a local package cache.
- The packages get listed in /etc/apk/world which gets saved with the lbu, for them to 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
APKOVL
kernel boot parameter.- If you don't have a web server you can run busybox's httpd temporarily to serve an .apkovl -
busybox httpd -p 127.0.0.1:80
.
- If you don't have a web server you can run busybox's httpd temporarily to serve an .apkovl -
- To customize the boot sequence further, one may refer to PXE boot#Specifying an apkovl and How to make a custom ISO image with mkimage.
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.
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.
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.