diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 00000000..e69de29b diff --git a/404.html b/404.html new file mode 100644 index 00000000..ac3a75fb --- /dev/null +++ b/404.html @@ -0,0 +1,624 @@ + + + +
+ + + + + + + + + + + + + + + + + + +These exmaples used Docker Compose syntax. See the Installation section to fit them into your configuration.
+Remember the folder naming convention
+container-name
must match the source
and destination
folder names.Don't have all your container volumes in the same directory? That's okay, we can use Docker volume mappings to help.
+This config allows additional volumes outside the traditional source
directory.
volumes:
+ # Standard config
+ - /var/run/docker.sock:/var/run/docker.sock
+ - /source:/app/source
+ - /destination:/app/destination
+ # Alternative source directories examples
+ - /opt/pihole:/app/source/pihole #(1)!
+ - /mnt/docker_volumes/plex:/app/source/plex #(2)!
+
source
directorysource
directoryWe added 2 additional source volumes: pihole
and plex
. The end result will have a source directory inside the Nautical container that looks like this:
<Nautical Backup>/app/source:
+- container1-data #(1)!
+- container2-data #(2)!
+- pihole # Mapped from /opt/pihole
+- plex # Mapped from /mnt/docker_volumes/plex
+
/source
directory/source
directoryThis config uses volumes only outside the traditional source
directory.
volumes:
+ # Standard config
+ - /var/run/docker.sock:/var/run/docker.sock
+ - /destination:/app/destination #(1)!
+ # Alternative source directories examples
+ - /opt/pihole:/app/source/pihole
+ - /opt/trilium:/app/source/trilium
+ - /mnt/docker_volumes/plex:/app/source/plex
+ - /var/data/portainer:/app/source/portainer
+
source
directories, the destination
directories will all be the same:
+ /destination/pihole
+/destination/trilium
+/destination/plex
+/destination/portainer
+
This configuration allows us to map as many container data folders as we'd like from any source directory. +
<Nautical Backup>/app/source:
+- pihole # Mapped from /opt/pihole
+- trilium # Mapped from /opt/trilium
+- plex # Mapped from /mnt/docker_volumes/plex
+- portainer # Mapped from /var/data/portainer
+
We can also remap the distination directory for any container we'd like.
+volumes:
+ # Standard config
+ - /var/run/docker.sock:/var/run/docker.sock
+ - /source:/app/source #(1)!
+ - /destination:/app/destination
+ # Alternative destination directories examples
+ - /opt/pihole-backup:/app/destination/pihole
+ - /mnt/docker_volume-backups/plex:/app/destination/plex
+
destination
directories, the source
directories are using the standard configuration:
+ /source/pihole
+/source/plex
+
This config allows the addition of volumes outside the traditional destination
directory.
We added 2 additional destination volumes: pihole
and plex
. The end result will have a destination directory inside the Nautical container that looks like this:
<Nautical Backup>/app/destination:
+- container1-data #(1)!
+- container2-data #(2)!
+- pihole # Mapped to /opt/pihole-backup
+- plex # Mapped to /mnt/docker_volume-backups/plex
+
/source
directory/source
directoryvolumes:
+ # Standard config
+ - /var/run/docker.sock:/var/run/docker.sock
+ - /source:/app/source #(1)!
+ # Alternative destination directories examples
+ - /opt/pihole:/app/destination/pihole
+ - /opt/trilium:/app/destination/trilium
+ - /mnt/docker_volumes/plex:/app/destination/plex
+ - /var/data/portainer:/app/destination/portainer
+
destination
directories, the source
directories will all be the same:
+ /source/pihole
+/source/trilium
+/source/plex
+/source/portainer
+
This configuration allows us to map as many container data folders as we'd like to any destination directory. +
<Nautical Backup>/app/destination:
+- pihole # Mapped to /opt/pihole
+- trilium # Mapped to /opt/trilium
+- plex # Mapped to /mnt/docker_volumes/plex
+- portainer # Mapped to /var/data/portainer
+
Nautical itself does not have the ability to map network shares. However, it can use a network share for either the source or destination.
+Commonly, we run containers on our host machine, then use an NFS share as the backup destination location. This page will give a brief overview of how to do that.
+Create the NFS destination directories. +
# Create mount point (1)
+mkdir -p /mnt/nfs/docker_backups
+
Setup NFS mount points: +
nano /etc/fstab
+
# | ------------- Source -------------- | ---- Destination ---- | -------- Options ---------- |
+192.168.1.10:/mnt/backups/docker_volumes /mnt/nfs/docker_backups nfs _netdev,auto,rw,async 0 0
+
192.168.1.10
is just an example IP address
+Apply and mount the NFS shares +
mount -a
+
A succesful mount -a
will return nothing in the console
Verify read and write access +
cd /mnt/nfs/docker_backups
+touch test.txt && rm test.txt
+
The above example created a local directory of /mnt/nfs/docker_backups
which is an NFS share pointing to 192.168.1.10:/mnt/backups/docker_volumes
.
Here is how we can use this new mount withing Nautical:
+version: '3'
+services:
+ nautical-backup:
+ image: minituff/nautical-backup:0.3.2 #(7)!
+ container_name: nautical-backup
+ volumes:
+ - /var/run/docker.sock:/var/run/docker.sock #(1)!
+ - /source:/app/source #(2)!
+ - /mnt/nfs/docker_backups:/app/destination #(3) <-- NFS Share
+
source
directory.destination
directory.0 4 * * *
- Every day at 4am.latest
tag.docker run -d \
+ --name nautical-backup \
+ -v /var/run/docker.sock:/var/run/docker.sock \ #(1)!
+ -v /source:/app/source \ #(2)!
+ -v /mnt/nfs/docker_backups:/app/destination \ #(2)!
+ minituff/nautical-backup:0.3.2 #(7)!
+
source
directory.destination
directory.0 4 * * *
- Every day at 4am.latest
tag.Nautical does not provide connectivity to remote services such as S3, B2, or Google Drive. We believe there are better tools for these jobs and think it is best not to recreate them.
+Here is a list of a few of our favorite solutions:
+Ideally, you would configure Nautical to create a backup at a destination
folder, then point that folder to a remote backup solution.
Nautical provides configuration in the form of Docker enviornment variables.
+See the Installation Section, which contains a few examples of applying enviornment variables.
+If a container has an Enviornment Variable applied as well as a conflicting Label, then:
+++The continer Label takes priority over the global Natical enviornment variable.
+
Sets the time-zone to be used by the CRON schedule. If this environment variable is not set, Nautical will use the default time-zone: Etc/UTC
.
To change the time-zone, see this Wikipedia page, find your location and use the value in TZ Database Name
, e.g America/Los_Angeles
.
++Default: Etc/UTC
+
TZ=America/Los_Angeles
+
docker exec nautical-backup date
+Allow changing the schedule for when the backup is started.
+++Default: 0 4 * * *
+
CRON_SCHEDULE=0 4 * * *
+
Tell Nautical to skip backup of containers in this list.
+This list can either be the container name
or full id
.
++Default: empty (no skips)
+
SKIP_CONTAINERS=container-name1,container-name2,container-name3
+
SKIP_CONTAINERS=container-name1,056bd2e970c1338782733fdbf1009c6e158c715d0d105b11de88bd549430e7f5
+
Getting the full container ID
+Usally, it's easier to just use the container-name
, but if you need to use the full ID, these commands will help:
docker ps --no-trunc
docker inspect <container name>
🔄 This is the same action as the Disable Nautical label, but applied globally.
+Require the Docker Label nautical-backup.enable=true
to be present on each contianer or it will be skipped.
++Default: false
+
REQUIRE_LABEL=true
+
See the Enable or Disable Nautical Label Section for more details.
+Allows a source directory and container-name that do not match.
+++Default: empty (use container name)
+Format:
+<container-name>:<local source folder name>
(comma seperated for multiple items)
Normally a container is backed up only when the container-name
is the exact same as the source folder name
.
For example, a container named Pi.Alert
will be skipped with a source directory name of pialert
.
+To fix this, we can override the source directory name so that it does not need to match the container name.
OVERRIDE_SOURCE_DIR=Pi.Alert:pialert
+
We can override multiple containers if we seperate them with a comma. +
OVERRIDE_SOURCE_DIR=example1:example1-new-source-data,ctr2:ctr2-new-source
+
Container Name | +Old Source Directory | +New Source Directory | +
---|---|---|
example1 | +src/example1 |
+src/example1-new-dest-data |
+
ctr2 | +src/ctr2 |
+src/newdest |
+
🔄 This is the same action as the Override Source Directory label, but applied globally.
+Changes the destination backup name to be something other than the container name.
+++Default: empty (use container name)
+Format:
+<container-name>:<new destination folder name>
(comma seperated for multiple items)
Normally, a container is backed to a folder with the same name as the container-name
.
For example, let's say we have a container named Pi.Alert
. By default, the container will be backed up to a folder named Pi.Alert
.
+If we want to change this destination folder name to be pialert
, we can do that using overrides.
OVERRIDE_DEST_DIR=Pi.Alert:pialert
+
OVERRIDE_DEST_DIR=example1:example1-new-dest-data,ctr2:newdest
+
The example above would yield the following results:
+Container Name | +Old Destination Directory | +New Destination Directory | +
---|---|---|
example1 | +dest/example1 |
+dest/example1-new-dest-data |
+
ctr2 | +dest/ctr2 |
+dest/newdest |
+
🔄 This is the same action as the Override Destination Directory label, but applied globally.
+Enable or Disable the automatically generated report file.
+++Default: true
+
REPORT_FILE=true
+
Bypass stopping the container before performing a backup. This can be useful for containers with minimal configuration.
+++Default: empty (no containers will be skipped)
+
SKIP_STOPPING=example1,example2
+
Not stoppping containers can produce corrupt backups.
+Containers with databases--particularly SQL--need to be shutdown before backup.
+Only do this on containers you know for certain do not need to be shutdown before backup.
+🔄 This is the same action as the Stop Before Backup label, but applied globally.
+Will immediatly perform a backup when the container is started in addition to the CRON sheduled backup.
+++Default: false
+
BACKUP_ON_START=true
+
Set the console log level for the container.
+++Default: INFO
+Options: DEBUG, INFO, WARN, ERROR
+
LOG_LEVEL=INFO
+
Set the log level for the generated report file. +Only used if the repot file is enabled.
+++Default: INFO
+Options: DEBUG, INFO, WARN, ERROR
+
REPORT_FILE_LOG_LEVEL=INFO
+
Use the default rsync
arguemnts -raq
(recursive, archive, quiet)
Useful when using Custom rsync Arugments
+++Default: true
+
USE_DEFAULT_RSYNC_ARGS=false
+
🔄 This is the same action as the Use Default rsync Arguments label, but applied globally.
+Apply custom rsync
args (in addition to the default args)
++Default: empty (no custom rsync args will be applied)
+
There are many rsync
arguments and customizations that be be used here.
# Don't backup any .log or any .txt files
+RSYNC_CUSTOM_ARGS=--exclude='*.log' --exclude='*.txt'
+
The RSYNC_CUSTOM_ARGS
will be inserted after the $DEFAULT_RSYNC_ARGS
as shown:
+
rsync $DEFAULT_RSYNC_ARGS $RSYNC_CUSTOM_ARGS $src_dir/ $dest_dir/
+
🔄 This is the same action as the Custom rsync Arguments label, but applied globally.
+
+
{"use strict";/*!
+ * escape-html
+ * Copyright(c) 2012-2013 TJ Holowaychuk
+ * Copyright(c) 2015 Andreas Lubbe
+ * Copyright(c) 2015 Tiancheng "Timothy" Gu
+ * MIT Licensed
+ */var Ha=/["'&<>]/;Un.exports=$a;function $a(e){var t=""+e,r=Ha.exec(t);if(!r)return t;var o,n="",i=0,s=0;for(i=r.index;i