When testing the connection via ssh forced command, if the remote path
is an empty directory (instead of nonexistent), the handler bails even
tough the connection is successful.
Co-authored-by: Emil Breiner <emil.breinr@krumedia.com>
The code added in the previous commit is only relevant for the mirror
format. With the long format, directories are created correctly in the
rotation routine. For the short format, the directory is initially
created, but only for a local destination, so adding a short snippet to
the rotation routine does it.
Before it was only possible to backup root directories (depth one, eg.
/etc, /var, /usr, …). For example consider the following truncated toy
configuration for rsync:
[general]
mountpoint = /media/
backupdir = backup
[source]
include = /foo/bar
include = /etc
We assume you have prepared the existent but empty base-directory
/media/backup/ at your destination, then against the expectation, the
following error rises:
rsync: mkdir "/media/backup/foo/bar/" failed: No such file or directory (2)
The reason is that rsync will take the files from the folder /foo/bar/
and tries to put them into the ulitmate – and therefore existent –
destination /media/backup/foo/bar. This is not what you would expect,
since the prepared directory /media/backup exists and the application
should create the rest itself.
This Merge Request adds a little script which creates the required
directories in the destination before running rsync. It assumes that
the base-directory already exists, so that not too much directories
are created automatically (could be a mess if you accidentally type the
wrong path)
* also validate desthost and destuser when desturl undefined
* move desturl vs destuser/host/dir warning in sanity checks section
* ensure includes are specified
* drop checks on local destination, duplicity autocreates directory
* add some needed whitespace
On some workloads, a process creating backups should not become so
aggressive on resources that it prevents normal activity of a machine
from running. It is especially important when writing to disk.
One way to make backups have less impact on the main workload is to
force backups to a lower ionice level.
With the new ionicelevel configuration, it becomes possible for users to
activate the use of ionice and to define the level within the
best-effort class to better suit their needs.
Since the luks headers backup was introduced in the handler, cryptsetup
has gained the "luksHeaderBackup" command. We should use this instead
of dd, as it is likely more reliable. Plus, it supports backing up luks
version 2 headers, which the current code doesn't handle.
The previous sfdisk-based command would also list partitions, leading to
partition-based luks volumes being duplicated. Instead, reuse the same
command used in the partition backup component.
The check for the string length in the condition for appending the $create_options fails because it isn't a string. Fixed with quoting the variable.
Change-Id: I6bdacb81f25cf924dc61e3aa6f4b8ebfbe09da65
Signed-Off-By: Emil Breiner <emil.breiner@krumedia.com>
borg will by default create its cache directory in ~/.cache/borg. This
means that during backup runs, borg will read and write quite
extensively from/to this directory.
In some situations, it is rather undesirable to have this amount of IO
activity in this location and it would make sense to tell borg to place
its cache elsewhere. This can help for example with placing the cache on
a hard drive where the added IO load will not have as big of an impact
on other running activity for the system.
This change also makes sure that the cache directory environment
variable is cleared out when the configuration option is unset. This
should avoid unpleasant surprises when this environment variable is set
to some unknown value in the context where backupninja is called, which
could lead to borg reading and writing to random places on the system.
This enables the handlers to be used for hosts which use a non-standard
port, such as is offered by some commercial services. Default to port
22, so it's optional and backwards-compatible.
It seems like only the short output of hwinfo --disk is provided to hardware.txt. I'd suggest we also add disk to the flags for the "complete" output.
That's especially useful when you need to indicate the serial number of a dead drive in order for it to be replaced. Once the disk is dead, using hardware.txt can be the only way to retrieve this info.
