Make switching to backrest easier?

[ovizii]

I'm wondering whether it would be possible to add say an alias to a backrest plan?

The intention is to have backrest treat snapshots it finds in a repository with this alias as part of this plan. Thus making it easier to transition from using restic via cmd line or via some wrapper to backrest without losing backup history or having to manage/prune with two different tools?

Say my plan is called daily-docs and I could add alias xyz I'd see all snapshots taken by this plan and all external ones with the tag: xyz as belonging to this plan, so backrest could run its purge over all of these snapshots.

Is something like this possible?

Otherwise, switching would create a lot of a mess or work :-/ and backrest is really nice and easy to use ;-)

[garethgeorge]

This is a good point w.r.t. switching to backrest. If I have time this would make good wiki content, but for now I'll document my thoughts here!

I think this is complicated enough (and will vary enough based on how users scripted their setups prior to adopting backrest) that there isn't a one size fits all approach that I'd want to implement and maintain in backrest, but because backrest builds on the restic cli there are a lot of options for scripting a move to backrest on the cli.

Backrest organizes snapshots into plans based on tags. Backrest adds a tag to each snapshot that indicates the plan it is grouped under e.g. plan:<plan ID> so if you have a plan foo, you can group a snapshot under that plan by adding the tag plan:foo.

Gemini comes up with a script looking like:

#!/bin/bash

export RESTIC_REPOSITORY="/path/to/your/restic/repo"
export RESTIC_PASSWORD="your_strong_password"

# Get a list of all snapshot IDs using 'restic snapshots' and save to an array
snapshot_ids=( $(restic snapshots --json | jq -r '.[].id') )

# Loop over each snapshot ID and add the tag "foo"
for snapshot_id in "${snapshot_ids[@]}"
do
  restic tag --set 'plan:foo' $snapshot_id
done

that's untested some tweaking may be needed.

[ovizii]

Thanks, I've taken your idea and modified it a little for autorestic which is the restic wrapper I have been using until now.

I have a few things hardcoded here as I was too lazy to pass them as variables so let me explain:
— onedrive1tb – this is the name of the autorestic repository
— /opt/media – this is the location of the previous snapshots (you can also grep for Tags if you like)
— plan:arr-libraries – this is the name of the plan I would like to adopt my old pre-backrest snapshots done with autorestic

#!/bin/bash

# idea from: https://github.com/garethgeorge/backrest/discussions/142#discussioncomment-8671983

# Get a list of all snapshot IDs using 'autorestic snapshots' and save to an array
snapshot_ids=( $( autorestic exec -vb onedrive1tb -- snapshots | grep '/opt/media' | awk '{print $1}') )

# Loop over each snapshot ID and add the tag "foo"
for snapshot_id in "${snapshot_ids[@]}"
do
  autorestic exec -va -- tag --set 'plan:arr-libraries' $snapshot_id
# test
#  echo $snapshot_id
done

This worked perfectly and replaced the old tags which these snapshots had with my new plan tag. Backrest picked them up upon re-indexing snapshots on this repository.

[ovizii]

I do however have a problem with backrest pruning this plan.

I have checked the number of snapshots in this plan and visually checked with backrest and they both agree, there are 20 snapshots in this plan.

autorestic exec -vb onedrive1tb -- snapshots | grep 'plan:arr-libraries' | awk '{print $1}' | wc -l
20

This plan is set to keep the last 8 snapshots:

  "retention": {
    "keepLastN": 8
  }

I ran a prune via backrest by clicking on my plan, then on "prune now". The prune ran and this is its output:

command: /data/restic-0.16.4 prune -o sftp.args=-oBatchMode=yes --max-unused 25%
loading indexes...
loading all snapshots...
finding data that is still in use for 291 snapshots
[0:52] 100.00%  291 / 291 snapshots

searching used packs...
collecting packs for deletion and repacking
[0:13] 100.00%  33183 / 33183 packs processed


to repack:             0 blobs / 0 B
this removes:          0 blobs / 0 B
to delete:             0 blobs / 0 B
total prune:           0 blobs / 0 B
remaining:       2856842 blobs / 545.168 GiB
unused size after prune: 188.476 MiB (0.03% of remaining size)

done

I'm still left with 20 snapshots. Not sure what I am doing wrong here.

[ovizii]

Hm, it looks like when a backup plan gets executed it runs a backup, then a snapshot, followed by a “forget” and a “prune”. Last night my scheduled plan ran and successfully pruned the forgotten snapshots. All is well, but this is something that should make it into a wiki entry someday.
###edit###
Apologies, I found the info in the wiki: https://github.com/garethgeorge/backrest/wiki/Backup-Lifecycle-&-Automation-Details