Hi, I have installed and configured Amanda on my system but I am recieving an error and would kindly like to ask community for any hint what could be wrong. Thanks in advance!
My setup:
RPI 3, openhabian installation, running and booting from 16GB micro SD card (shrinked to 10GB to avoid potential issues when reimaging to another 16GB card which is few sectors smaller maybe as well as to decrease the time needed for full backup).
Directly to RPI is attached external 2,5" 60GB HDD, mounted to /mnt/HDD formated to NTFS as I wanted to easily copy backup files also to my WIN PC. Maybe this (NTFS) is the issue, I am not sure, but from what I read, this should work. I have enabled on RPI the higher power for USB and the HDD worked normally until I installed Amanda and run the first backup.
After Amanda installation (the improved readme is now really helpful and I read it about 3 times as well as this discussion before I started the installation so big thanks to @mstormi and others) there were correctly created folders and subfolders on the HDD (I am using only the option with local storage, not the Amazon nor NAS) although, I have inserted as the mount point during the Amanda setup the path in this format: â/mnt/HDD/â including the last slash, which was maybe not correct as Amanda in amreport reffered to â/mnt/HDD//slots/driveâŠâ with double slahes after HDD so the slash was there from my input in the installation as well as Amanda probably added it itself. But as the folder structure on the mounted HDD semeed to be successfully created by amanda, I kept it for the first time as it was (those double slashes). Maybe the installation script could be adjusted to avoid this in the future or the readme could mention that.
Whatever, I have manually run the first backup and after several hours checked with amreport which showed some errors (unfortunately do not have it there was some issue with the raw backup of the card). I couldnât access the HDD from the RPI (I tried list directories on HDD using ls but didnât work). However, there WERE created some files on the HDD and I was able to access the HDD after RPI reboot. So I let that be and there was the first overnight backup scheduled by cron.
I had again an error though and the HDD was somehow locked again. So I edited the amanda.conf to correct the double slashes in the path to HDD mount so now is:
tpchanger "chg-disk:/mnt/HDD/slots" # The tape-changer glue script
and installed the mailing on RPI so amanda could send me reports via email (btw very easy guideline to use gmail account for sending emails from RPI is here, maybe itâs worth add the link to the readme as well). So finally I received the log into my email:
Hostname: openHABianPi
Org : openHABian openhab-dir
Config : openhab-dir
Date : bĆezen 22, 2018
These dumps were to tape openHABian-openhab-dir-002.
Not using all tapes because taper found no tape.
No dumps are left in the holding disk.
The next 10 tapes Amanda expects to use are: 10 new tapes.
FAILURE DUMP SUMMARY:
openHABianPi /dev/mmcblk0 lev 0 FAILED [data write: Connection reset by peer]
openHABianPi /dev/mmcblk0 lev 0 partial taper: Error writing device fd 6: Input/output error
openHABianPi /dev/mmcblk0 lev 0 FAILED [data write: Broken pipe]
openHABianPi /dev/mmcblk0 lev 0 partial taper: taper found no tape
STATISTICS:
Total Full Incr. Level:#
-------- -------- -------- --------
Estimate Time (hrs:min) 0:15
Run Time (hrs:min) 0:27
Dump Time (hrs:min) 0:00 0:00 0:00
Output Size (meg) 1.3 0.0 1.3
Original Size (meg) 1.3 0.0 1.3
Avg Compressed Size (%) 100.0 -- 100.0
DLEs Dumped 2 0 2 1:2
Avg Dump Rate (k/s) 538.2 -- 538.2
Tape Time (hrs:min) 0:11 0:11 0:00
Tape Size (meg) 1.3 0.0 1.3
Tape Used (%) 0.0 0.0 0.0
DLEs Taped 4 2 2 1:2
Parts Taped 4 2 2 1:2
Avg Tp Write Rate (k/s) 2.0 0.0 6700.0
USAGE BY TAPE:
Label Time Size % DLEs Parts
openHABian-openhab-dir-002 0:11 2380828k 69.8 4 4
FAILED DUMP DETAILS:
/-- openHABianPi /dev/mmcblk0 lev 0 FAILED [data write: Connection reset by peer]
sendbackup: info BACKUP=APPLICATION
sendbackup: info APPLICATION=amraw
sendbackup: info RECOVER_CMD=/bin/gzip -dc |/usr/lib/amanda/application/amraw restore [./file-to-restore]+
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
\--------
/-- openHABianPi /dev/mmcblk0 lev 0 FAILED [data write: Broken pipe]
sendbackup: info BACKUP=APPLICATION
sendbackup: info APPLICATION=amraw
sendbackup: info RECOVER_CMD=/bin/gzip -dc |/usr/lib/amanda/application/amraw restore [./file-to-restore]+
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
\--------
NOTES:
planner: Adding new disk openHABianPi:/dev/mmcblk0.
planner: Last full dump of openHABianPi:/etc/openhab2 on tape openHABian-openhab-dir-001 overwritten in 1 run.
planner: Last full dump of openHABianPi:/var/lib/openhab2 on tape openHABian-openhab-dir-001 overwritten in 1 run.
planner: WARNING: no history available for openHABianPi:/var/lib/openhab2; guessing that size will be 51730 KB
planner: WARNING: no history available for openHABianPi:/etc/openhab2; guessing that size will be 1465 KB
taper: Slot 2 without label can be labeled
taper: Slot 3 without label can be labeled
taper: tape openHABian-openhab-dir-002 kb 1340 fm 3 [OK]
taper: while labeling new volume: Error checking directory /mnt/HDD/slots/drive2/data/: No such file or directory
DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOSTNAME DISK L ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s
-------------------------------- ---------------------- -------------- --------------
openHABianPi /dev/mmcblk0 0 -- PARTIAL 10:58 0.0 PARTIAL
openHABianPi /etc/openhab2 1 20 20 -- 0:01 18.3 0:00 200.0
openHABianPi /var/lib/openhab2 1 1320 1320 -- 0:01 945.7 0:00 13200.0
(brought to you by Amanda version 3.3.9)
The storagestate file contains:
$STATE = {
'meta' => undef,
'drives' => {
'/mnt/HDD/slots/drive1' => {},
'/mnt/HDD/slots/drive2' => {},
'/mnt/HDD//slots/drive1' => {},
'/mnt/HDD//slots/drive0' => {
'pid' => 10185
}
}
};
Of course I googled the input/output error and most of the links says that the HDD is corrupted. However, this seems strange as after RPI restart it works normally. I am not experienced so can only think of some access rights issues, which is strange if amanda could create folders as well as some filesâŠ
Here is the content of my openhab-dir if that helps (bĆe = March):
openhabian@openHABianPi:/etc/amanda/openhab-dir $ ls -lh
celkem 24K
-rw-r--r-- 1 root root 13 bĆe 20 13:11 amanda-client.conf
-rw-r--r-- 1 root root 2,8K bĆe 21 22:21 amanda.conf
-rw-r--r-- 1 root root 2,8K bĆe 21 21:01 amanda.conf.bkp
-rw-r--r-- 1 root root 144 bĆe 20 13:11 disklist
-rw------- 1 backup backup 450 bĆe 22 10:36 storagestate
-rw------- 1 backup backup 122 bĆe 22 01:26 tapelist
-rw------- 1 backup backup 0 bĆe 20 14:01 tapelist.lock
This is the content of the slots folder on HDD (suprisingly I can ls it now without the reboot):
openhabian@openHABianPi:/mnt/HDD/slots $ ls -lh --color=auto
celkem 8,5K
lrwxrwxrwx 1 root root 18 bĆe 22 10:36 data -> slot3
drwxrwxrwx 1 root root 0 bĆe 20 13:47 drive0
drwxrwxrwx 1 root root 0 bĆe 22 01:00 drive1
drwxrwxrwx 1 root root 4,0K bĆe 20 14:01 slot1
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot10
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot11
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot12
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot13
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot14
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot15
drwxrwxrwx 1 root root 4,0K bĆe 22 01:15 slot2
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot3
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot4
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot5
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot6
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot7
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot8
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot9
and the content of the slot1 folder:
openhabian@openHABianPi:/mnt/HDD/slots/slot1 $ ls -lh --color=auto
celkem 3,0G
-rwxrwxrwx 1 root root 32K bĆe 20 14:01 00000.openHABian-openhab-dir-001
-rwxrwxrwx 1 root root 102M bĆe 20 14:01 00001.openHABianPi._var_lib_openhab2.0
-rwxrwxrwx 1 root root 2,9M bĆe 20 14:01 00002.openHABianPi._etc_opì§nhab2.0
-rwxrwxrwx 1 root root 2,9G bĆe 20 14:15 00003.openHABianPi._dev_mmcblk0.0
slot2 content (other slots are empty):
openhabian@openHABianPi:/mnt/HDD/slots/slot2 $ ls -lh --color=auto
celkem 2,2G
-rwxrwxrwx 1 root root 32K bĆe 22 01:15 00000.openHABian-openhab-dir-002
-rwxrwxrwx 1 root root 52K bĆe 22 01:15 00001.openHABianPi._etc_openhab2.1
-rwxrwxrwx 1 root root 1,4M bĆe 22 01:15 00002.openHABianPi._var_lib_openhab2.1
-rwxrwxrwx 1 root root 2,2G bĆe 22 01:25 00003.openHABianPi._dev_mmcblk0.0
So it seems to me that only the first manually run backup worked (with error that I do not have) but not the automated ones. May this really be the ownership issue as the owner of the slot folders seems to be root so user backup canât write there? If yes, I thought that he amanda installation should take care of that⊠Is the chown the solution then? It would be strange anyway as the first manual backup I started logged as backup user.
Thanks a lot for any hint!
UPDATE 22.03.2018 14:10
I have created new profile for testing that is backing up only small folder with influxdb data, using same settings for slots and tapes copied from openhab-dir and it works! See the log from email:
Hostname: openHABianPi
Org : openHABian influx-dir
Config : influx-dir
Date : bĆezen 22, 2018
These dumps were to tape openHABian-influx-dir-001.
The next 10 tapes Amanda expects to use are: 10 new tapes.
STATISTICS:
Total Full Incr. Level:#
-------- -------- -------- --------
Estimate Time (hrs:min) 0:00
Run Time (hrs:min) 0:00
Dump Time (hrs:min) 0:00 0:00 0:00
Output Size (meg) 15.6 15.6 0.0
Original Size (meg) 15.6 15.6 0.0
Avg Compressed Size (%) 100.0 100.0 --
DLEs Dumped 1 1 0
Avg Dump Rate (k/s) 4536.2 4536.2 --
Tape Time (hrs:min) 0:00 0:00 0:00
Tape Size (meg) 15.6 15.6 0.0
Tape Used (%) 0.5 0.5 0.0
DLEs Taped 1 1 0
Parts Taped 1 1 0
Avg Tp Write Rate (k/s) 15990.0 15990.0 --
USAGE BY TAPE:
Label Time Size % DLEs Parts
openHABian-influx-dir-001 0:00 15990k 0.5 1 1
NOTES:
planner: Adding new disk openHABianPi:/var/lib/influxdb/data.
planner: WARNING: no history available for openHABianPi:/var/lib/influxdb/data; guessing that size will be 1000000 KB
taper: Slot 3 without label can be labeled
taper: Slot 4 without label can be labeled
taper: tape openHABian-influx-dir-001 kb 15990 fm 1 [OK]
big estimate: openHABianPi /var/lib/influxdb/data 0
est: 1000032k out 15990k
DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOSTNAME DISK L ORIG-kB OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s
------------------------------------- ---------------------- -------------- --------------
openHABianPi /var/lib/influxdb/data 0 15990 15990 -- 0:04 4535.4 0:01 15990.0
(brought to you by Amanda version 3.3.9)
and the slots content now (slot3 used for the influx-dir backup):
[14:12:42] backup@openHABianPi:/mnt/HDD/slots$ ls
celkem 8,5K
lrwxrwxrwx 1 root root 18 bĆe 22 14:08 data -> slot4
drwxrwxrwx 1 root root 0 bĆe 20 13:47 drive0
drwxrwxrwx 1 root root 0 bĆe 22 01:00 drive1
drwxrwxrwx 1 root root 4,0K bĆe 20 14:01 slot1
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot10
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot11
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot12
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot13
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot14
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot15
drwxrwxrwx 1 root root 4,0K bĆe 22 01:15 slot2
drwxrwxrwx 1 root root 360 bĆe 22 14:08 slot3
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot4
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot5
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot6
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot7
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot8
drwxrwxrwx 1 root root 0 bĆe 20 13:10 slot9
and the content of the slot3 folder:
[14:14:16] backup@openHABianPi:/mnt/HDD/slots/slot3$ ls
celkem 16M
-rwxrwxrwx 1 root root 32K bĆe 22 14:08 00000.openHABian-influx-dir-001
-rwxrwxrwx 1 root root 16M bĆe 22 14:08 00001.openHABianPi._var_lib_influxdb_data.0
