Has my backup succeeded?

At the end of 'obnamhome.txt' there is a block of text which is very interesting to see how your backup has gone -

2013-09-04 16:31:48 INFO Backup performance statistics:
2013-09-04 16:31:48 INFO \* files found: 163789
2013-09-04 16:31:48 INFO \* files backed up: 21474
2013-09-04 16:31:48 INFO \* uploaded data: 160170561 bytes (152.75055027 MiB)
2013-09-04 16:31:48 INFO \* duration: 1901.63381505 s
2013-09-04 16:31:48 INFO \* average speed: 82.2537768516 KiB/s
2013-09-04 16:31:48 INFO Backup finished.
2013-09-04 16:31:48 INFO obnam version 1.5 ends normally

but you don't need to see this every-time it runs if you've got cron set up to send you an email on successful cronjob running. And the email it sends me says this for this backup -

'Backed up 21474 files (of 163789 found), uploaded 152.8 MiB in 31m42s at 82.3 KiB/s average speed. Sending Backup report : Backup of obnam-home completed'

To get cron to send you an email on successful completion you need to put this in it near the top -

MAILTO=$USER@foobar

substituting your username in place of $USER, and the machine name in place of foobar. You also need to put this line in 'notify-send' -

echo -e "Sending Backup report : Backup of obnam-home completed"

Lock timeout

Sooner or later you'll get a email stating that there is a lockfile which needs clearing before you can proceed with other backups. Before clearing it, you need to find out why its locked? It could've timed out, or there could be some other reason. Once you've sorted it out, the command to release the lockfile is -

obnam [options] force-lock

Depending on which backup is concerned, you may have to put the path to its config file in the [options] place like this -

obnam --config=/etc/obnamvar.conf force-lock

Further information can be found at http://liw.fi/obnam/locking/

An obnam bug that may bite you

You may get an error report that says like this -

ERROR: Node 0x2a166 cannot be found in the node store 17580577608458113855:
 2: No such file or directory: /media/boudiccas/backup/obnam-home/17580577608458113855/nodes/21/0/0/2a166

This is a long known bug and at the moment the only way round it is as follows -

  • rename the numbered directory
  • do a full backup again
  • then it should work as normal from thereon.

Its hoped that this bug will be fixed in the next release of obnam.

Obnam forget

Although obnam only keeps one copy of each file the amount of drive space that it can consume can be quite large, and even though hard drives are comparitivily cheap at the moment, we need to be aware of the space that's used. You can find this information with 'filelight' or your file manager. Just for information my 'obnam-home' backup was 394.8gb on the 18th August.

Because the backup can grow quite large there is the option of obnam forget which is where this enigmatic entry in each conf file comes into play keep = 8h,14d,10w,12m. This essentially keeps the last 8 hours worth of backups, the last 14 days, the last 10 weeks, and the last 12 months too.

To quote from the man page 'A typical policy might be 72h,7d,5w,12m, which means: keep the last 72 hourly backups, the last 7 daily backups, the last 5 weekly backups and the last 12 monthly backups. If the backups are systematically run on an hourly basis, this will mean keeping hourly backups for three days, daily backups for a week, weekly backups for a month, and monthly backups for a year'

This can be run from a cron job to really automate it, or you can just run it by hand from the commandline at some pre-determined schedule of your own, like on the 1st of each new month.

However, if no policy is given, forget will keep everything! And the way the policy works is a bit complicated. Run forget with the --pretend option to make sure you're removing the right ones.

obnam ls

Using this command and piping it to a text file, it lists the contents of a given generation, and if no generation is given then it defaults to the most recent one -

obnam ls>~/cron/backedup-obnam.txt

This can be useful if you need to restore a file or two.



Comments

comments powered by Disqus