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… 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:
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
that’s not how it’s supposed to be, right? so, now what?
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.
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
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
So now if you just repeat the same steps, guess what will happen again …
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).
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.
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.
i have a backup of /dev/sda1:
