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
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.
thanks for the quick reply. You are right a directory with special caracters is not a goot idea and not from me . 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 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
openhabian@openHABianPi:~ $
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!
If you had fully read the Amanda README you would have noticed that it tells you that it cannot be run on top of CIFS. The reason is that I actually ran into those very same issues you describe and couldn’t resolve them (and as a longtime UNIX admin, I’m sure the problem is on the CIFS/Windows side).
I suggest you just move your USB storage to your Pi and run Samba there to serve your other clients.
Dear @mstormi,
Thank you for your quick reply. I have read the Readme and still, I was wondering if there’s any explanation for this behavior. But I guess you would have figured it out if it was a solvable problem.
I’ll go with the USB mount then.
Thank you for your time!
I finally managed to setup NFS to use Amanda.
I still have some questions:
Somewhere I read that it is possible to setup up Amanda to store the internal database also on the NAS, in order to have this backed up as well.
How to change the path for the database?
Is it possible to move the existing database to another path?
In order to send email is is required to set up the email on openhabian.
Is there a setup available?
Not easily (IIRC it requires recompilation).
You can move dirs to NAS and replace the original with links.
But there’s no need. Install from openHABian should have created a cron entry that’ll take care of copying the database to your storage area once day.
Setup what for, a mail relay ? Latest openHABian will offer to install exim. It should have asked you when installing Amanda. Unless you didn’t upgrade openhabian which is the first thing you should do after flashing (start openhabian-config, it’ll ask you to upgrade itself).
Thanks mstormi for the fast answer. I still have some questions regarding Amanda Database.
Your HowTo says that the cron job in /etc/cron.d/amanda will take care about copying index and config files. I have had a look in this cron job on my raspberry and it looks like this:
If I understand correctly, this will check the server reachability each day at 18:00 and wil run the actuyl backup at 1:00. I don’t see copying index files or configurations.
I’ve just installed Amanda a couple of days before and even the complete openHABian is a quite fresh install (~1 month).
That sounds a bit weird, because I assume “some time ago” is more than a month, right?
Yes. Could you please check /opt/openhabian/functions/backup.sh around line 23 if the code to generate the entry is there.
Looking at the code now I believe I already see the problem, $tapetype isn’t set at that stage.
Just fixed that in openHABian.
You can manually edit /etc/cron.d/amanda but if you don’t mind helping wait for move Amanda DB copy cronjob creation to proper stage by mstormi · Pull Request #544 · openhab/openhabian · GitHub to be merged and re-run Amanda install to test the fix and let me know
That’s just my own cron entry. It’s generated on Amanda install with the storage dir you tell it.
I would like to backup the openhab-dir on daily bases and additionally backup the complete SD let’s say once a month. What is the best way to do this?
I assume I have to set up another backup config. e.g. openhabian-SDcard and schedule this via cron to once a month.
But I wonder If I have to use another mount to distinguish between openhab-dir and openhabian-SDcard.
Not easy to answer. A second config is an option yes and you mustn’t use the same storage dir.
Or add/remove the partition from the disklist file via cronjob.
There’s more options in tweaking parameters in amanda.conf but that sort of thing you want is in contrast to the way Amanda works so not easy to figure out a config to do exactly that.
Best thing is to let it handle dumpcycle and dumplevels automatically and to not try to be smarter than it.
Can you please edit /opt/openhabian/functions/backup.sh and add a \ in front of the $ in line 120 (the one to create the cron entry), then reinstall Amanda from the menu and show the cron entry.
. It was created maybe during the installation. I choose the option “Install Amanda Backup” on the openhabian menu. The folder 
