alexjurkiewicz / acts Goto Github PK

Noticed that I've got daily backup files reaching back to August of 2019. Ran acts from command line, got a slew of delete notices, but the ran the tarsnap list command string and all those daily backups still live on.

Any guidance?

Found a situation where I'm not getting a yearly backup for new backup locations. Looks like the test for presence of host-yearly-year ignores the backup target.

I’m packaging acts for the nix package manager, and it would help if the paths to the configuration file weren’t hardcoded.

Are you open to this change? If so, I could probably come up with a PR.

Hi there again,
While fiddling with the other issue, I was thinking that acts could implement a "prune only" mode.

I faked it by setting $backuptargets to empty just in the Backup section (nicely organized btw) but it would be awesome to have a proper way to do that.

Again,
thank you for the script, it's really neat!

This line has the wrong logstring (pre instead of post)

*) printf '\-%s' "$dirname" ;;
With this code the archive always entails a backslash.

(I'm just starting to configure acts, so please forgive me if I'm confused).

When I run acts with no arguments, it fails with:
# acts
/usr/local/bin/acts: 1: parameter not set
Exit

I suspect this is due to the "set -u", followed quickly by: if [ "$1" ...
That is, $1 isn't set since I have no command line arguments, which triggers the shell to terminate the program.

# sh -x /usr/local/bin/acts
+ set -u
+ set -e
+ VERSION=1.2
/usr/local/bin/acts: 1: parameter not set
Exit 2

Running on FreeBSD 10.2.

Hi there and thanks for this tool, I use it regularly and with great delight 😄

There is a problem I think on deletion I cannot really identify: every time there is a backup to prune it kind of gets stuck at this:

Debug: daily
Debug: message="More than 31 daily backups, deleting the oldest"
Info: message="Deleting backup prefix xyz-daily-2020-12-02_18:19:16-var*"
Debug: message="Deleting backup xyz-daily-2020-12-02_18:19:16-var"
<stuck here>

I tried to delete the backup with vanilla tarsnap and it did that in no time.

I wonder what that can be? Any hint on how to debug?

I know it's just a simple shell script, but still life would be simpler for some of us if you added a license...

It would be nice if the generated archive names did not have the noisy backslash inserted (currently done to prevent the initial hyphen breaking printf I guess).

Also, I'd like it if the timestamp were optional - I'd prefer to have just the date in the archive name.

Thanks for acts!

running it within cygwin on windows so far so good at least i think so.

where / how do i view the logs that it looks like it is logging so i can see its progress?

i'm assuming it must be about half way through backing up my folders but have no feedback to make sure it is getting the correct files.

thank you in advanced

I'm using the .deb to install to a production machine on a Ubuntu 12.04 machine. It requires coreutils 8.21, but 12.04 maxes out at 8.13. Do you think running with 8.13 will cause problems?

I haven’t actually deployed ACTS yet, so forgive me and close this out if I’m misinterpreting the code.

It looks like each backup will either be daily, monthly, or yearly. This means that the first two days of the year won’t have a daily backup.

Consider instead always doing a daily backup, and then copying to monthly/yearly as needed.
tarsnap -c -f monthlybackup @@dailybackup

The copy operation is pretty trivial in terms of data transfer, and that way there is always a daily, monthly, and yearly backup.

Is it possible to backup a directory that contain a space in its name?

I tried escaping it like directory\ name but acts didn't like it.

acts-1.0
tarsnap 1.0.35
cygwin

This may be a niche problem, and it's entirely likely that I'm misusing tarsnap, but I have carefully set nodump flags throughout my filesystem, and run tarsnap --nodump -c /.

Setting backuptargets="/" works, but leads to strange-looking archive names. ACTS essentially unsets $nicedirname, leading to a dangling hyphen (host-type-date-). Setting $backuptargets to . produces odd names too (host-type-date-.). More ideal would be to just leave $nicedirname off entirely in that case (host-type-date).

Consider then:

if [ "$dir" = "/" ]; then
    nicedirname=""
else
    nicedirname=$(echo "-$dir" | tr -d '/')

and s/-$nicedirname/$nicedirname/.

My use case involves backing up user data, and not the system itself. For example, I want to backup /pool/UserData1 and /pool/UserData2. Since these files are not in the root directory, and I don't want extraneous characters in my tarsnap archive names, I added a new variable "$backuproot", which tarsnaps relative to that instead of /.

> git diff acts
diff --git a/acts b/acts
index da1f966..0728751 100755
--- a/acts
+++ b/acts
@@ -137,13 +137,13 @@ fi
 # PART 3: Backup
 backuprc=0 # Notice any failed backups
 for dir in $backuptargets ; do
-    log_verbose "Backing up /$dir..."
+    log_verbose "Backing up $backuproot/$dir..."
     archive_starttime=$(date +%s)
     nicedirname=$(echo "$dir" | tr -d '/')
     # Uncontrolled expansion is bad, but we have little choice. See https://github.com/koalaman/shellcheck/wiki/Sc2086
     # shellcheck disable=SC2086
-    if ! output="$($tarsnap -c -f "$hostname-$archivetype-$today-$nicedirname" -C / $tarsnapbackupoptions "$dir" 2>&1)" ; then
-        log_message "Failed to back up \"$dir\"! ($output)"
+    if ! output="$($tarsnap -c -f "$hostname-$archivetype-$today-$nicedirname" -C $backuproot $tarsnapbackupoptions "$dir" 2>&1)" ; then
+        log_message "Failed to back up \"$backuproot/$dir\"! ($output)"
         backuprc=1
     fi
     archive_endtime=$(date +%s)

I don't actually know how to use git, so I hope this diff is sufficient if you want to include this for real. Note that acts.conf.sample should also be updated to include this variable. I have tested this for my one use case, but I probably messed things up, so please test first. :)

I'm assuming having the archive names contain the timestamp relative to UTC time rather than local time was a design decision. I find the behavior slightly disorienting (my local time is 10 hours ahead of UTC, so typically even the date is off). Wouldn't local time be more generally useful?