| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
They contain no useful information and increase the length of the
autogenerated options documentation.
See discussion in #18816.
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
modules: optionSet -> submodule
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
Crashplan: 4.6.0-r2 -> 4.6.0-r3
|
| | |
| |
| |
| | |
applied fully
|
| |\|
| |
| | |
Crashplan 46 r2
|
| | | |
|
| |\ \
| |/
|/| |
znapzend: added
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
| |
* the major change is to set TARGETDIR=${vardir}, and symlink from
${vardir} back to ${out} instead of the other way around. this
gives CP more liberty to write to more directories -- in particular
it seems to want to write some configuration files outside of conf?
* run.conf does not need 'export'
* minor tweaks to CrashPlanDesktop.patch
|
| | |
|
| |
|
|
|
|
| |
- add missing types in module definitions
- add missing 'defaultText' in module definitions
- wrap example with 'literalExample' where necessary in module definitions
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two concurrent tarsnap backups cannot be run at the same time with the
same keys - completely separate sets of keys must be generated for each
archive in this case, if you want backups to overlap.
This extends the archives attrset to support a 'keyfile' option, which
defaults to /root/tarsnap.key like the top-level attribute.
With this change, if you generate two keys with tarsnap-keygen(1) and
use each of those separately for each archive, you can backup
concurrently.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tarsnap locks the cachedir during backup, meaning if you specify
multiple backups with a shared cache that might overlap (for example,
one backup may take an hour), secondary backups will fail. This isn't
very nice behavior for the obvious reasons.
This splits the cache dirs for each archive appropriately. Note that
this will require a rebuild of your archive caches (although if you were
only using one archive for your whole system, you can just move the
directory).
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A machine may not always be active (or online!) when a backup timer
triggers, meaning backups can be missed - now we properly set the
tarsnap timer's Persistent option so systemd will run the command even
when the machine wasn't online at that exact time.
However, we also need to make sure that we can contact the tarsnap
server reliably before we start the backup. So, we attempt to ping the
access endpoint in a loop with a sleep, before continuing.
This fixes #8823.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
| |
|
|
|
|
|
| |
This reverts commit 5f0253ace683bae4c7989f4db167676dd0a507e7.
I didn't intend to push this - I meant to push it to *my fork's*
remote...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tarsnap locks the cachedir during backup, meaning if you specify
multiple backups with a shared cache that might overlap (for example,
one backup may take an hour), secondary backups will fail. This isn't
very nice behavior for the obvious reasons.
This splits the cache dirs for each archive appropriately. Note that
this will require a rebuild of your archive caches (although if you were
only using one archive for your whole system, you can just move the
directory).
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
| | |
|
| | |
|
| |
|
|
| |
types.int already implies uniqueness.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Annoyingly, these do not appear to accept SI prefixes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Major changes
- Port to systemd timers: for each archive configuration is created a
tarsnap@archive-name.timer which triggers the instanced service unit
- Rename the `config` option to `archives`
Minor/superficial improvements
- Restrict tarsnap service capabilities
- Use dirOf builtin
- Set executable bit for owner of tarsnap cache directory
- Set IOSchedulingClass to idle
- Humanize numbers when printing stats
- Rewrite most option descriptions
- Simplify assertion
|
| | |
|
| |
|
| |
Usage of pkgs.lib may cause infinite recursion
|
| |\
| |
| |
| |
| | |
Crashplan
OK, it is an external service with unfree client, so let's declare that ensuring usability of the service is not our headache.
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
Should bring most of the examples into a better consistency regarding
syntactic representation in the manual.
Thanks to @devhell for reporting.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| | |
|
| |
|
|
|
|
|
|
| |
The Tarsnap module is now far more flexible, allowing individual
archives with individual options to be specified at will, allowing
granular backup schedules, etc.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
| |
|
|
|
|
|
|
| |
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
|
| | |
|
| |
|
|
| |
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
| | |
|
| |
|
|
| |
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
| |
|