Amanda howto for openhabian and NAS

@mstormi

I noticed (although a bit late) that the suggested cron job doesn’t run successfully because of the embedded date command. Here is my syslog, you see the command is cut off.

Apr 15 02:00:01 localhost CRON[21712]: (root) CMD ((cd /; tar czf /mnt/schoofiserver2/amanda_data_$(date +)

Currently it looks like I was able to solve this changing brackets to …whatever this new character is called :wink: and escaping the percentage character. Here my own cronjob example:

(I used a screenshot as the forum editor malformes the command)

and that this is fixed I have a new issue :wink: Amanda was working fine for me (after struggling in the beginning). Now it seems my “tapes” are full. but how do I virtually add a new tape or overwrite the oldest tape?

amcheck
$ amcheck openhab-dir
Amanda Tape Server Host Check
-----------------------------
slot 15: volume ‘openHABian-openhab-dir-014’ is still active and cannot be overwritten
slot 1: volume ‘openHABian-openhab-dir-001’ is still active and cannot be overwritten
slot 2: volume ‘openHABian-openhab-dir-001’ is still active and cannot be overwritten
slot 3: volume ‘openHABian-openhab-dir-002’ is still active and cannot be overwritten
slot 4: volume ‘openHABian-openhab-dir-003’ is still active and cannot be overwritten
slot 5: volume ‘openHABian-openhab-dir-004’ is still active and cannot be overwritten
slot 6: volume ‘openHABian-openhab-dir-005’ is still active and cannot be overwritten
slot 7: volume ‘openHABian-openhab-dir-006’ is still active and cannot be overwritten
slot 8: volume ‘openHABian-openhab-dir-007’ is still active and cannot be overwritten
slot 9: volume ‘openHABian-openhab-dir-008’ is still active and cannot be overwritten
slot 10: volume ‘openHABian-openhab-dir-009’ is still active and cannot be overwritten
slot 11: volume ‘openHABian-openhab-dir-010’ is still active and cannot be overwritten
slot 12: volume ‘openHABian-openhab-dir-011’ is still active and cannot be overwritten
slot 13: volume ‘openHABian-openhab-dir-012’ is still active and cannot be overwritten
slot 14: volume ‘openHABian-openhab-dir-013’ is still active and cannot be overwritten
volume ‘’
Taper scan algorithm did not find an acceptable volume.
(expecting a new volume)
ERROR: No acceptable volumes found
Server check took 1.356 seconds

ameport

*** A TAPE ERROR OCCURRED: [No acceptable volumes found].
No dumps are left in the holding disk.

The next 10 tapes Amanda expects to use are: 1 new tape, openHABian-openhab-dir-001, openHABian-openhab-dir-002, openHABian-openhab-dir-003, openHABian-openhab-dir-004, openHABian-openhab-dir-005, openHABian-openhab-dir-006, openHABian-openhab-dir-007, openHABian-openhab-dir-008, openHABian-openhab-dir-009.
FAILURE DUMP SUMMARY:
  smarthome /dev/mmcblk0 lev 0  FAILED [can't do degraded dump without holding disk]
  smarthome /etc/openhab2 lev 0  FAILED [can't do degraded dump without holding disk]
  smarthome /var/lib/openhab2 lev 0  FAILED [can't do degraded dump without holding disk]

You’re right on escaping the percentage but wrong on the backquote (that’s how it’s called :wink: ), that isn’t guaranteed to work in cron (I wonder it does for you). I’ve changed the PR to now match what I’ve been successfully running locally.
@ThomDietrich maybe you could give that PR a review and a go.

1 Like

Hmm, there’s various possible reasons but the most likely one is that you have defined too few (virtual) tapes (tapecycle setting in amanda.conf, asked for at setup time) to cover the timeframe we want to be able to restore back to (dumpcycle setting, 2 weeks per default).
Note that if your tape length (tapetype DIRECTORY definition) is too small for a single dump to fit in which will easily be the case for a level 0 dump, Amanda uses as many tapes as needed so at some point the oldest one is still “not old enough” to reuse it.
Try to manually increase the tape length (tapetype) to be larger than a single level 0 dump.
Try to reduce dumpcycle, or to increase tapecycle, or both. Note you need to manually create directories and ‘amlabel’ these if you increase tapecycle. See manpage for amlabel command and /opt/openhabian/functions/backup.sh how to use it.
As that only applies to future dumps, if Amanda still tells you all tapes are active, you could try freeing one of your tapes using amrmtape command.
In general, have a look at this Wiki article.

thanks a lot, but this is a bit of information overflow for me :wink: Can you help me to analyze?

That’s what’s in my config and to me it looks good

dumpcycle 2 weeks
tapecycle 15 tapes
lengtgh 3333 mbytes

I believe in the very first beginning I tried to use amdump a few times during the day. could it be that more than one slot have been used for this? And now I’ve reached the end of the slots but 2 weeks haven’t passed yet?

EDIT:
This is what I’ve found in ‘tapelist’. Take a look at timestamps for openHABian-openhab-dir-001 and openHABian-openhab-dir-002

20180414010001 openHABian-openhab-dir-014 reuse BLOCKSIZE:32
20180413010001 openHABian-openhab-dir-013 reuse BLOCKSIZE:32
20180412010001 openHABian-openhab-dir-012 reuse BLOCKSIZE:32
20180411010001 openHABian-openhab-dir-011 reuse BLOCKSIZE:32
20180410010002 openHABian-openhab-dir-010 reuse BLOCKSIZE:32
20180409010002 openHABian-openhab-dir-009 reuse BLOCKSIZE:32
20180408010002 openHABian-openhab-dir-008 reuse BLOCKSIZE:32
20180407010001 openHABian-openhab-dir-007 reuse BLOCKSIZE:32
20180406010001 openHABian-openhab-dir-006 reuse BLOCKSIZE:32
20180405103557 openHABian-openhab-dir-005 reuse BLOCKSIZE:32
20180405010001 openHABian-openhab-dir-004 reuse BLOCKSIZE:32
20180404010001 openHABian-openhab-dir-003 reuse BLOCKSIZE:32
20180403153638 openHABian-openhab-dir-002 reuse BLOCKSIZE:32
20180403153638 openHABian-openhab-dir-001 reuse BLOCKSIZE:32
0 Tape-16 reuse BLOCKSIZE:32

I’ve now added another free slot. Let’s see what happens next

Stefan

yes

You could use amrmtape to remove some of those old dumps/free those tapes

If by that you mean you just added a line to tapelist that’s not sufficient thus no good idea.
You need to create the directories and amlabel them, as I said see what the openhabian install routine does.

Latter is exactly what I did :wink: Will take a look at amrmtape. Thanks for your fantastic support.

@mstormi

me again :slight_smile: would be great if you can point me into the right direction.

Now that my backup is running fine since weeks I need to take a look at the restore scenario. In my case it’s a raw disk restore (of my EMMC).

I wonder if it’s possible to restore and overwrite the same running linux version?! I mean, I boot the device which contains an “empty” Linux. I install amanda. Then I run the restore command. Will this work?

Or do I need to boot the OS that will be used to trigger the restore in a different way, like from network and keep in RAM? No clue if this is even possible.

Stefan

Well, you can do that as long as you have access to the storage file and Amanda index database on that ‘fresh’ box (i.e. mount from NAS or whatever). It even would work without that index but it’s sort of a hack then, see ‘emergency’ section in Amanda Readme.
But why would you want to do that ?
You cannot overwrite the partition you’re actively running Linux off, restores ever need to go to ‘inactive’ partitions only. Yes you can boot your box from the network, but that’s not easy to accomplish for if possible at all (depends on HW and OS).
Best option is to get an external eMMC card writer (if that’s why you’re asking) and restore there, can be done from your active OH box.

thx for the reply.

I will test the following and keep the forum informed. My OrancePi can boot from SDCard or integrated EMMC. I will try to boot from a prepared SD Card (with amanda files in place) and then restore to EMMC. Just waiting for delivery of the ordered hardware :wink:

Should work but be aware it takes time and means to take down your OH box.
Try if to restore to SD (from your box running off the eMMC) works as well.

I’d rather not touch my running system :wink: waiting for the backup hardware so I can run some tests without touching the production

Hi Markus,

I’m back. Meanwhile my recovery device (just a second OrangePi) has arrived and my first full restore scenario has been tested successfully.

Anyway, I think you need to add one more important thing to openhabians amanda cronjob:

In order for the restore to be successful I cloned the amanda server/client files which are backed up every night. Unfortunately amfetchdump complained about missing log files. So I changed my cronjob to this:

0 2 * * * root (cd /; tar czf /mnt/MYSERVER/amanda_data_$(date +%Y%m%d%H%M%S).tar.gz /var/log/amanda /etc/amanda /var/lib/amanda; find /mnt/MYSERVER -name amanda_data_* -mtime +10 -delete) >/dev/null 2>&1

Btw: I described what I did to restore the dump on my blog. http://blog.haupt.xyz/index.php/Disaster-Recovery
If you want to have a look, scroll down to: Recovery device / Perform restore

best regards

Stefan

Guess amfetchdump still worked, didn’t it ? It’s just the logs, these one usually does not backup (you can but I wouldn’t make it the default).

this is how I tried to restore and it doesn’t work for me as long as the logs are missing.

backup@orangepi-restore:/tmp$ amfetchdump -p openhab-dir smarthome /dev/mmcblk0 20180703 > /mnt/myserver/restoreimage
Warning: no log files found for tape openHABian-openhab-dir-004 written 2018-07-04 01:00:02
Warning: no log files found for tape openHABian-openhab-dir-003 written 2018-07-03 01:00:01
Warning: no log files found for tape openHABian-openhab-dir-002 written 2018-07-02 01:00:02
Warning: no log files found for tape openHABian-openhab-dir-001 written 2018-07-01 01:00:02
Warning: no log files found for tape openHABian-openhab-dir-015 written 2018-06-30 01:00:02
Warning: no log files found for tape openHABian-openhab-dir-014 written 2018-06-29 01:00:01
Warning: no log files found for tape openHABian-openhab-dir-013 written 2018-06-28 01:00:02
Warning: no log files found for tape openHABian-openhab-dir-012 written 2018-06-27 01:00:01
Warning: no log files found for tape openHABian-openhab-dir-011 written 2018-06-26 01:00:02
Warning: no log files found for tape openHABian-openhab-dir-010 written 2018-06-25 01:00:02
Warning: no log files found for tape openHABian-openhab-dir-009 written 2018-06-24 01:00:01
Warning: no log files found for tape openHABian-openhab-dir-008 written 2018-06-23 01:00:02
Warning: no log files found for tape openHABian-openhab-dir-007 written 2018-06-22 01:00:02
Warning: no log files found for tape openHABian-openhab-dir-006 written 2018-06-21 01:00:02
Warning: no log files found for tape openHABian-openhab-dir-005 written 2018-06-20 01:00:02
ERROR: No matching dumps found

if logs are in place, it answers like this:

backup@orangepi-restore:/tmp$ amfetchdump -p openhab-dir smarthome /dev/mmcblk0 20180703 > /mnt/myserver/restoreimage
1 volume(s) needed for restoration
The following volumes are needed: openHABian-openhab-dir-003
Press enter when ready

Hi all,
I have Openhab 2.3 running on a Raspi3 with Openhabian 1.4.1.
Now I tried Amanda Backup. Backup medium is a synology. The installation went through without errors but at the end the owner of the files */slots/ could not be changed.
Updating FireMotD available updates count …
chown: der Eigentümer von ‘/home/shares/backup//amanda-backups’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot3’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/drive1’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot12’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot6’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot2’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot11’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot7’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot1’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot14’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot4’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot5’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot13’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot9’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot8’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot15’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/drive0’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot10’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/amanda-backups’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/@eaDir/@tmp’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/@eaDir’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/’ wird geändert: Das Argument ist ungültig
2018-07-13_10:53:43_CEST [openHABian] Checking for default openHABian username:password combination… OK
2018-07-13_10:53:44_CEST [openHABian] We hope you got what you came for! See you again soon :wink:

Does anyone have an idea?

Dirk

Your problem seems to be with ownership or access rights change that the openHABian Amanda setup script executes. You’ve probably used bad options when you mounted your share from your NAS (UID mapping) or your NAS-side rights configuration is bad in terms of access rights…

Also, a directory with an special characters, namely an @ in the name, is a bad idea. You cannot expect all scripts to properly handle that. Try with a proper name and don’t backup to any directory that already has contents at Amanda setup time.

Hi Markus,

thanks for the quick reply. You are right a directory with special caracters is not a goot idea and not from me :slight_smile:. It was created maybe during the installation. I choose the option “Install Amanda Backup” on the openhabian menu. The folder @eaDir and @tmp (subfolder from @eaDir)

I didn’t create the folders. Can I delete it?

I tried it again after I deleted the @directories, but with the same result.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 7 nicht aktualisiert.
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots’ wird geändert: Das Argument ist ungültig
chown: der Eigentümer von ‘/home/shares/backup/amanda-backups’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot3’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/drive1’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot12’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot6’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot2’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot11’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot7’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot1’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot14’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot4’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot5’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot13’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot9’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot8’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot15’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/drive0’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots/slot10’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/slots’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup/amanda-backups’ wird geändert: Das Argument ist ungültig
/bin/chown: der Eigentümer von ‘/home/shares/backup’ wird geändert: Das Argument ist ungültig
2018-07-13_21:38:25_CEST [openHABian] Checking for default openHABian username:password combination… OK
2018-07-13_21:38:25_CEST [openHABian] We hope you got what you came for! See you again soon :wink:
openhabian@openHABianPi:~ $

any advice?

Again, dirnames aren’t your problem, it’s with your rights setup. Obviously the setup script (running as root unless you made a mistake there) should be able to create and change ownership/rights of the subdirectories, but it cannot because your NFS setup is bad. You aren’t using CIFS, are you ??.
You could start a root shell on your openhabian and try creating directories and change ownership/rights in the storage dir manually and you should see the same problem. You can lookup the commands openhabian issues on setup in /opt/openhabian/functions/backup.sh.
root@client (openhabian) is commonly mapped to some non-root UID on the NAS, that’s possibly why.
Sorry but that you have to debug yourself.

Hi,
I know I’ll put me into distrust right away but is there any chance to run Amanda with a CIFS NAS?
Namely, I have a fritzbox NAS share and already tried to mount it via cifs using gid/uid backup, did a chown of the backup folder, added backup to sudoers and and and.
As user backup I can create and modify dirs and files on the target NAS. All the slot folders are created during setup, but drive0 symlink fails with permission denied.
I work with unix quite a lot but I’m honestly lost at this point. Am I right that it should work, once the user backup has full rights on the target nas dir?
Thank you!

Bob