All,
Anyone who uses Amanda for a 32 GB SD-card image backup?
According to Amanda in openhabian-config it is not recommended above 8GB.
Thanks in advance.
It was me to write it is not recommended because to dump 32GB on a Pi can take very long and there were reports of people whose Pi has locked up.
You can enter the partitions you want to backup instead of the whole disk.
If you have a 32 GB card, most of it will be empty so it doesn’t make sense to backup all those zeroes anyway.
Hmm… backing up empty space is weird. That makes sense. 
So backing up the whole SD-Card (on a separate sd card reader) would make more sense then.
I like the sd-Card image backup, because it’s fast to replace without any addition reconfiguration.
Default Amanda config actually does backup the raw device that points to the whole SD, so you can use Amanda restore to create a clone copy.
But yes, if you have a separate SD writer, it’s easier to use that. I use dd if=/dev/mmcblk0 of=/dev/sdc bs=1M (my card reader shows up as sdc).
Hi @mstormi,
I am preparing the migration to 2.2 stable and openhabian 1.4
But if I want to backup the SSD (replaced the standard SD-card) I get an error, that it cannot be read:
/dev/mmcblk0 can't be read
I encountered the same issue after I connected the SSD to my Laptop to create an image with Win32DiskImager.
What can I do to make it readable?
EDIT:
OOPS… I just recognized that I dont’t have any /dev/mmcblk0 at all.
df brings:
Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/root 30728784 2831152 26623816 10% /
devtmpfs 492508 0 492508 0% /dev
tmpfs 497116 0 497116 0% /dev/shm
tmpfs 497116 50400 446716 11% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 497116 0 497116 0% /sys/fs/cgroup
/dev/sda1 41322 21426 19897 52% /boot
192.168.178.39:/volume1/openhab/backup 2879515136 1834206336 1045206400 64% /mnt/nfs/openhab/backup
So, how can I include my SSD to create an image of it?
Don’t understand, what are you talking about - a SD card or your SSD ?
/dev/mmcblk0 is the internal SD reader device, but I think it only shows up if you boot from there. Not sure if it’s showing up with a different name if you boot from a different device. Try fdisk -l
Now as you apparently did boot from elsewhere (SSD probably). why do you want to backup the (unused) SD card ?
If you want to backup your SSD in Amanda, add a line with its raw device name to the disklist file.
I guess that’s /dev/sda in your case.
Thanks for your quick response. Sorry, my post above is a little confusing and I will correct it soon.
Actually I do not have any SD-card, but replaced it with a SSD - and I would like to back it up.
fdisk -l shows:
fdisk: cannot open /dev/ram0: Keine Berechtigung (no access rights)
fdisk: cannot open /dev/ram1: Keine Berechtigung
fdisk: cannot open /dev/ram2: Keine Berechtigung
fdisk: cannot open /dev/ram3: Keine Berechtigung
fdisk: cannot open /dev/ram4: Keine Berechtigung
fdisk: cannot open /dev/ram5: Keine Berechtigung
fdisk: cannot open /dev/ram6: Keine Berechtigung
fdisk: cannot open /dev/ram7: Keine Berechtigung
fdisk: cannot open /dev/ram8: Keine Berechtigung
fdisk: cannot open /dev/ram9: Keine Berechtigung
fdisk: cannot open /dev/ram10: Keine Berechtigung
fdisk: cannot open /dev/ram11: Keine Berechtigung
fdisk: cannot open /dev/ram12: Keine Berechtigung
fdisk: cannot open /dev/ram13: Keine Berechtigung
fdisk: cannot open /dev/ram14: Keine Berechtigung
fdisk: cannot open /dev/ram15: Keine Berechtigung
fdisk: cannot open /dev/sda: Keine Berechtigung
I will adjust the disklist config manually and might come back with new questions… 
you need to be root … und ich hab keine große Lust jetzt alle UNIX Basics erklären zu sollen, wenn du schon nicht das Standard-Setup nutzen willst … da google dann bitte selber.
Of course.
Sorry, I did not want to upset you.
I was just confused that an SSD instead of SD-card does not work with the openhabian amanda approach.
No offense. - I will figure it out.
Well, that’s the idea of a standard setup and what you get if you deliberate choose to deviate from it. Sorry, aber die Spitze kann ich mir jetzt nicht verkneifen.
fdisk -l should show you all attached disk-like devices, incl. your SSD. Manually edit disklist file and enter the partitions you want Amanda to backup into disklist, one line for each partition (and of course not just the partition name(s) alone, you need to match the format of disklist lines)
Fair enough - Alles gut
Of course openhabian cannot cover all use cases - I am happy that openhabian even exists
So I am just fine with it so far, but I just needed a little nudge towards the disklist file and the different /dev representing my SSD within the system.
I edited the disklist file and just replaced /dev/mmcblk0 with my /dev/sda:
Backup is running and I will wait for the results.
Note /dev/sda is the device for the whole disk (just as is /dev/mmcblk0). From general experience, restoring that might turn out to be a problem (as restoring might also overwrite the master boot record), but I have no specific experience with Pis and SSDs. Might work or not. Either way, you should do a test restore to ensure it’s working (to another SSD, of course). If it turns out to not work you should try to separately backup all /dev/sdaX partitions (multiple lines in disklist) instead.
Thanks for the suggestions. I will do two backups. One for the whole SSD and one with the two partitions, like:
Homer /dev/sda1 amraw
Homer /dev/sda2 amraw
Homer /etc/openhab2 user-tar
Homer /var/lib/openhab2 user-tar
Obviously it takes ages, so this is probably not the long term solution I will prefer
But after I spent a lot of time for setting up the current state, I need to have a backup.
(Even though I am keen on switching over to 2.2
It seems that the backup was successful:
START taper datestamp 20171219134605 label openHABian-openhab-dir-016 tape 1
INFO taper Slot 2 without label can be labeled
INFO dumper gzip pid 11584
INFO dumper pid-done 11574
SUCCESS dumper Homer /dev/sda1 20171219134605 0 [sec 18.121 kb 30413 kps 1678.3 orig-kb 41984]
PART taper openHABian-openhab-dir-016 1 Homer /dev/sda1 20171219134605 1/-1 0 [sec 19.008447 bytes 31142397 kps 1599.920288 orig-kb 41984]
DONE taper Homer /dev/sda1 20171219134605 1 0 [sec 19.000000 bytes 31142397 kps 1600.631579 orig-kb 41984]
STATS driver estimate Homer /dev/sda1 20171219134605 0 [sec 18 nkb 42016 ckb 30464 kps 1601]
INFO dumper gzip pid 11610
INFO dumper pid-done 11610
SUCCESS dumper Homer /dev/sda2 20171219134605 0 [sec 2710.753 kb 2795343 kps 1031.2 orig-kb 31220566]
PART taper openHABian-openhab-dir-016 2 Homer /dev/sda2 20171219134605 1/-1 0 [sec 2709.866078 bytes 2862430344 kps 1031.542489 orig-kb 31220566]
DONE taper Homer /dev/sda2 20171219134605 1 0 [sec 2710.000000 bytes 2862430344 kps 1031.491513 orig-kb 31220566]
STATS driver estimate Homer /dev/sda2 20171219134605 0 [sec 2716 nkb 31220598 ckb 2794880 kps 1029]
INFO dumper pid-done 11584
SUCCESS dumper Homer /etc/openhab2 20171219134605 0 [sec 2731.451 kb 81520 kps 29.8 orig-kb 81520]
PART taper openHABian-openhab-dir-016 3 Homer /etc/openhab2 20171219134605 1/-1 0 [sec 8.973227 bytes 83476480 kps 9084.803048 orig-kb 81520]
DONE taper Homer /etc/openhab2 20171219134605 1 0 [sec 2734.000000 bytes 83476480 kps 29.817118 orig-kb 81520]
STATS driver estimate Homer /etc/openhab2 20171219134605 0 [sec 20 nkb 81552 ckb 81568 kps 4076]
INFO dumper gzip pid 16170
INFO dumper pid-done 16170
SUCCESS dumper Homer /var/lib/openhab2 20171219134605 0 [sec 18.407 kb 186660 kps 10140.3 orig-kb 186660]
PART taper openHABian-openhab-dir-016 4 Homer /var/lib/openhab2 20171219134605 1/-1 0 [sec 20.772391 bytes 191139840 kps 8985.966035 orig-kb 186660]
DONE taper Homer /var/lib/openhab2 20171219134605 1 0 [sec 20.000000 bytes 191139840 kps 9333.000000 orig-kb 186660]
STATS driver estimate Homer /var/lib/openhab2 20171219134605 0 [sec 25 nkb 186692 ckb 186720 kps 7466]
What’s puzzling me is the size of the (raw) backup partition files:
Shouldn’t it be the full size shown in fdisk -f?
Device Boot Start End Sectors Size Id Type
/dev/sda1 8192 92159 83968 41M c W95 FAT32 (LBA)
/dev/sda2 92160 62533291 62441132 29,8G 83 Linux
But it’s smaller:
EDIT:
Obviously the .0 files are compressed and not raw without compression like I am used to when using Win32DiskImager.
I guess problem soved and hopefully a proper backup stored 
Hello @NCO, need a little advice for backup.
My openHAB is running on RPi3. I’m booting from sd-card,
but moved my system to an external usb ssd-drive by using openhabian:
Before moving to ssd I used to backup the whole sd-card with Win32DiskImage .
I liked it, because it was fast, easy & reliable.
Trying to do that with the ssd I’m having the same problem like you posted:
Because of that, since a couple of month, my only backup is: I just copy all files from the RPi to a WinPc.
Not satisfactory. (for example z-wave inclusions are not backed up)
Because it looks like we have similar setups and problems, I would like to know, where you ended up.
Which backup strategy do you practice now? And is it something you would recommend to others?
Thanks in advance!
Hi,
please read post 12 onwards.
I figured out, that /dev/mmcblk0 doesn’t make sense at all (it’s the SD-card, but I would like to backup SSD of course)
So I have changed the disklist file to the settings in post 14.
Check your setup before changing (might be the same with sda)
However, I just backed them up, but did not restore one of them yet 
A pity, I was interested in your experience about restoring your system.
What’s not clear to me.
Do you have two SSD connected to your RPi and backup from one to the other?
Hi and sorry for the delay.
Actually with the SSD I did not need to restore a backup since.
To your question:
I just have one SSD replacing the SD-card with this housing:
https://www.element14.com/community/docs/DOC-83477/l/desktop-computer-kit-with-expansion-board-that-can-turn-a-raspberry-pi-into-a-real-desktop-pc
At the moment I don’t use my ssd anymore because I’m not able to backup easily. I switched back to sd-card with all its disadvantages. But the housing looks pritty interesting. Maybe I will try that in the future.
Thank you for that information.