Amanda restoring partition "Permission denied"

Tags: #<Tag:0x00007f616fd351a8> #<Tag:0x00007f616fd34f00> #<Tag:0x00007f616fd34ca8>

Hi!
I was on openHab 2.4.0-1 until an hour ago i tried to update to newest stable via openhabian-config. now nothing works anymore… :dizzy_face: i have a backup of /dev/sda1:


date                host         disk      lv tape or file               file part status
2020-05-15 19:24:51 openHABianPi /dev/sda1  0 openHABian-openhab-dir-002    3  1/3 OK
2020-05-15 19:24:51 openHABianPi /dev/sda1  0 openHABian-openhab-dir-004    1  2/3 OK
2020-05-15 19:24:51 openHABianPi /dev/sda1  0 openHABian-openhab-dir-005    1  3/3 OK
2020-05-16 01:00:02 openHABianPi /dev/sda1  0 openHABian-openhab-dir-006    2  1/3 OK
2020-05-16 01:00:02 openHABianPi /dev/sda1  0 openHABian-openhab-dir-008    1  2/3 OK
2020-05-16 01:00:02 openHABianPi /dev/sda1  0 openHABian-openhab-dir-009    1  3/3 OK
[19:03:10] backup@openHABianPi:~$ amtape openhab-dir show
amtape: scanning all 15 slots in changer:
slot  10: unlabeled volume
slot  11: unlabeled volume
slot  12: unlabeled volume
slot  13: unlabeled volume
slot  14: unlabeled volume
slot  15: unlabeled volume
slot   1: date 20200515010001 label openHABian-openhab-dir-001
slot   2: date 20200515192451 label openHABian-openhab-dir-002
slot   3: date 20200515192451 label openHABian-openhab-dir-003
slot   4: date 20200515192451 label openHABian-openhab-dir-004
slot   5: date 20200515192451 label openHABian-openhab-dir-005
slot   6: date 20200516010002 label openHABian-openhab-dir-006
slot   7: date 20200516010002 label openHABian-openhab-dir-007
slot   8: date 20200516010002 label openHABian-openhab-dir-008
slot   9: date 20200516010002 label openHABian-openhab-dir-009

tried with

[19:03:35] backup@openHABianPi:~$ amfetchdump -p openhab-dir openhabianpi /dev/sda1 20200516010002  > /server/temp/openhabianpi-image
-su: /server/temp/openhabianpi-image: No such file or directory

user backup can’t create /server/temp, and when i created the directory with root backup couldn’t create the file:

[19:10:21] backup@openHABianPi:~$ amfetchdump -p openhab-dir openhabianpi /dev/sda1 20200516010002  > /server/temp/openhabianpi-image
-su: /server/temp/openhabianpi-image: Permission denied

must i set permissions for backup in /server/temp/ or am i missing something else?

Yes (chmod 777 /server/temp)
You can also redirect to elsewhere where the backup user already has write access.

1 Like

ok, this is officially a nightmare… with fixed permissions i could make another step:

[19:40:02] backup@openHABianPi:~$ amfetchdump -p openhab-dir openhabianpi /dev/sda1 20200516010002  > /server/temp/openhabianpi-image
3 volume(s) needed for restoration
The following volumes are needed: openHABian-openhab-dir-006 openHABian-openhab-dir-008 openHABian-openhab-dir-009
Press enter when ready

amfetchdump: 2: restoring split dumpfile: date 20200516010002 host openHABianPi disk /dev/sda1 part 1/UNKNOWN lev 0 comp .gz program APPLICATION

2578848 kb

but now the ssh terminal is blocked / not responsive and i can’t open a new ssh connection to my device :rage:

that’s not how it’s supposed to be, right? so, now what?

Yes it is.
So what, open another session

PS: why restore at all, you can also just downgrade openHAB

as i mentioned above: i can’t open another session (no timeout, but also: no login “mask”).
didn’t know that i could just downgrade…

should i just wait a while and hope the backup runs through?

edit: could this be an option:

You could also move that temporary recovered image file to your Windows PC that has a card writer, rename the file to have a .raw extension, and use Etcher or other tool in order to write the image to the card.

additional question here: as shown in opening post i have 3 files, i should probably combine them before writing to ssd?

You still can. apt-cache madison openhab2 to find the available versions; apt-get install openhab2=<version>, then once more for the openhab2-addons package (and eventually …-legacy if you use that).

Of course you can. Start another putty or whatever you use as your terminal.

It’s the mandatory first step and it takes the time it takes anyway, so why stop ?

If you stop the file restore you won’t have a working file to write to SD.

yeah, that’s what i did, but i can’t connect - stays like this:
2020-05-16 22_39_25-Clipboard
i can ping the ip address but i cannot connect.

i won’t be able to know when it’s done since i can’t login… and since you speak of “first step”… will there be anoter step - whit user interaction?

it can take a lot of time if the box is busy restoring your file.

write the file to SD ?

it’s close to 12 hours now and i still can’t connect to my raspberry. it’s a 60gb ssd, how much longer can i expect?

if first step finishes, how do i write the file so the SD?
with this command?

backup@pi:/server/temp$ dd bs=4M if=/server/temp/openhabianpi-image of=/dev/sda1

Then something went wrong.
/server mounted from a different machine, isn’t it ? Do you still see the file growing ?

Err, wait - you didn’t restore the SD contents to the SD itself, did you ?

yes.
Read the docs again. You may not expect me and others to explain every single step, you have to invest your own work there.

sure did. figured it out (by myself) this morning and made a hard-reset. did the same steps with remote-dir on NAS, amfetchdump runs again (until now without disconnect).

i read the docs multiple times but i’m a noob with basic linux understanding and so some things aren’t as logical as they should be.
since i can reach my raspberry during file restore i’m trying to fix the 2.5.4 setup… maybe the restore isn’t even needed…
in the meantime: thanks for your patience :wink:

So you tried to restore a file of 16GB (or whatever your SD size is) to a already partially filled filesystem on a card of 16GB. Now what’s wrong about that :roll_eyes:
So now if you just repeat the same steps, guess what will happen again …

as i figured it out i chose a NAS-mounted instead of /server/temp/ :wink:
corrected previous post!

mhm… after disabling z-wave binding (had two devices - both not really important) and a reboot most things work as before (2.4.).

in the meantime also the restoring process went through (but i didn’t write it to /dev/sda1). for my own interest (maybe someday i really have to restore a partion) and for every other noob out there, here’s what to do and what not:
make sure you have permissions

restore to a remote machine (or some USB device plugged into raspberry) and do not try to restore to sd-card/ssd:

ok, today i restored my last openhabian-image (/dev/sda1), copied the file to my windows machine and wrote the image (named openhabianpi-image.raw) to another ssd but when i swtich my working ssd with the new ssd openhabian isn’t reachable… (no ping, no ssh)
etcher went through without problems (it said that the image isn’t bootable but that’s how i should be - i moved openhabian from sd to ssd a long time ago and sd is still needed to boot).

what am i missing this time :frowning:

Moving root to USB is not a good idea and to move first, then to replace SSD is even worse.
I don’t know why you use Windows stuff in there. You should restore directly from Linux using dd.

But all of that does not relate to Amanda, that apparently did its job.

at the time there was the menu point in openhabian-config and i’m pretty sure it was considered a good idea (at the time).

i used windows because in the openhabian-amanda github page it says

agreed, but until i figure out how to get a backup running it doesn’t help a lot.

next step: write backup with another raspberry pi to ssd.
do i have to “link” the new ssd to the “boot-sdcard”?

i’m not going to overwrite my working openhabian-ssd :slight_smile:

The menu point is still available but now gives proper warnings first.
I never advocated for moving to SSD like many “clever” people on the forum still do today.
This mess of yours is sort of proof to that (sorry for you).

When you attach it to your running Pi it should show up as a new device that you would use as the target device using (WARNING, INCOMPLETE) dd of=/dev/sdX but yes you have to be VERY careful you do not overwrite your active SSD.
But as the windows approach does not work, this one likely will fail, too.

I’d set up a new system (and stay with SD with ZRAM enabled) and migrate OH config only,. but choice is yours.

1 Like

thanks for the info. I’m gonna get a rasp4 and give ZRAM a try. (gonna have to do a lot of reading…)

no need for a new box, just get another SD card.