Re: dump failed: [request failed: No route to host](too)
It may well be just that I can't see the wood for the trees when looking at logging but I can't find the problem :-( I'm running daily manual dumps of the FAILED DLE's to keep backups intact! I'm still getting the following: FAILURE DUMP SUMMARY: bentley Resources lev 1 FAILED [too many dumper retry: [request failed: No route to host]] bentley sysadmin lev 1 FAILED [too many dumper retry: [request failed: No route to host]] Apart from the two KVM hosts, all these systems are KVM Guests. The backup server is a KVM guest. Has anyone seen or know of issues that may occur with amanda on virtualised infrastructure? From my understanding of KVM networking between guests, whole network frames are dumped and picked up between them. This allows higher transport speeds. I've tested the throughput with iperf and have seen througput as high as 25Gbps. The following ipef session shows the connection between the failed guest, bentley, and the backup server. I've only shown the 'server' side results for iperf below: # systemctl stop xinetd # iperf -p 10080 -s Server listening on TCP port 10080 TCP window size: 85.3 KByte (default) [ 4] local 10.0.19.21 port 10080 connected with 192.168.0.3 port 39214 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.0 sec 20.5 GBytes 17.6 Gbits/sec [ 4] local 10.0.19.21 port 10080 connected with 192.168.0.3 port 39215 [ 4] 0.0-10.0 sec 20.7 GBytes 17.8 Gbits/sec [ 4] local 10.0.19.21 port 10080 connected with 192.168.0.3 port 39218 [ 4] 0.0-10.0 sec 21.3 GBytes 18.3 Gbits/sec [ 4] local 10.0.19.21 port 10080 connected with 192.168.0.3 port 39223 [ 4] 0.0-10.0 sec 21.4 GBytes 18.4 Gbits/sec Any clues/help for the above are appreciated. I'm now also getting some other strange errors that I've never seen before. These report as 'FAILED' but further on into the report they appear to have completed without issue. What do the error codes signify (e.g. FAILED [02-00098] etc.)? ---8<--- FAILURE DUMP SUMMARY: ---8<--- bentley ECN lev 0 FAILED [02-00098] bentley Repair lev 1 FAILED [06-00229] garage /var lev 1 FAILED [shm_ring cancelled] modena /usr/src lev 1 FAILED [12-00205] ---8<--- NOTES: planner: Last full dump of bentley:ECN on tape daily02 overwritten in 5 runs. planner: Last level 1 dump of bentley:ECN on tape daily01 overwritten in 4 runs. planner: Last full dump of bentley:Repair on tape daily07 overwritten in 2 runs. planner: Last full dump of garage:/var on tape daily01 overwritten in 4 runs. ---8<--- DUMP SUMMARY: DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s --- --- --- ---8<--- bentley ECN 0 19790 19790-- 0:03 7325.0 0:00 197900.0 bentley Repair110 0.00:00 4.2 0:00 0.0 garage /var 1 7000 7000-- 0:00 33341.0 0:00 7.0 modena /usr/src 1 190 147.40:04 3.3 0:00140.0 ---8<--- What are the error codes and did amanda dump these OK or not? Kind regards, Tom Tom Robinson IT Manager/System Administrator MoTeC Pty Ltd 121 Merrindale Drive Croydon South 3136 Victoria Australia T: +61 3 9761 5050 F: +61 3 9761 5051 E: tom.robin...@motec.com.au On 13/09/17 23:09, Jean-Louis Martineau wrote: > Tom, > > It is the system that return the "No route to host" error. > You should check your system log (on server, client, router, firewall, nat, > ...) for network error. > > Jean-Louis > > On 12/09/17 06:01 PM, Tom Robinson wrote: >> bump >> >> On 11/09/17 12:45, Tom Robinson wrote: >> > Hi, >> > >> > I've recently migrated our backup server from CentOS 5 to CentOS 7. I've >> > also upgraded from amanda >> > 3.3.7 to 3.4.5 >> > >> > The amcheck works fine and reports no issues. Yet, on backup runs on some >> > DLEs I get the error: >> > >> > dump failed: [request failed: No route to host](too) >> > >> > It also appears to be random as to which DLEs fail. Sometimes it's just >> > one or two on a client. >> > Other times it's all DLEs for a client. And, for any particular client it >> > can be a different DLE on >> > that client each day. >> > >> > Below is a dumper..debug log from the server. I'm not sure what to check >> > for in there. What other >> > logs should I check? >> > >> > Kind regards, >> > Tom >> > >> > Sun Sep 10 20:16:32.115899592 2017: pid 6088: thd-0x257f400: dumper: >> > close_producer_shm_ring >> > sem_close(sem_write 0x7fbc1588b000 >> > Sun Sep 10 20:16:32.115911222 2017: pid 6088: thd-0x257f400: dumper: >> > am_sem_close 0x7fbc1588b000 0 >> > Sun
PARTIAL dump on my Fedora 26
Hi, Backup of my workstation are only partial, I need som help where to check. Are there a combination of more than one problem? Extract from the email-report: FAILURE DUMP SUMMARY: centos7.opistogo.se / lev 1 FAILED [data read: recv error: Resource temporarily unavailable] centos7.opistogo.se / lev 1 was successfully retried uw000140.kank.se /boot lev 0 FAILED [data read: recv error: Resource temporarily unavailable] uw000140.kank.se /boot lev 0 FAILED [data read: recv error: Resource temporarily unavailable] uw000140.kank.se /boot lev 0 partial taper: successfully taped a partial dump The client centos7 are on same subnet as the backup-server. The client uw000140 are on an other subnet with a firewall between backup-server and client. In the debug-files on uw000140, i found lots of "write error to"-messages: [root@uw000140 ~]# egrep -c " write error to: Bad file descriptor" /var/log/amanda/amandad/amandad.201710040* /var/log/amanda/client/DailySet1/*.201710040* | egrep -v ':0$' /var/log/amanda/amandad/amandad.20171004004901.debug:743574 /var/log/amanda/amandad/amandad.20171004005007.debug:8695 /var/log/amanda/amandad/amandad.20171004005033.debug:8530 /var/log/amanda/amandad/amandad.20171004005055.debug:746479 /var/log/amanda/amandad/amandad.20171004005250.debug:2259690 /var/log/amanda/amandad/amandad.20171004005346.debug:2259069 [root@uw000140 ~]# egrep -c " write error to: Connection reset by peer" /var/log/amanda/amandad/amandad.201710040* /var/log/amanda/client/DailySet1/*.201710040* | egrep -v ':0$' /var/log/amanda/amandad/amandad.20171004004901.debug:1 /var/log/amanda/amandad/amandad.20171004005007.debug:1 /var/log/amanda/amandad/amandad.20171004005033.debug:1 /var/log/amanda/amandad/amandad.20171004005346.debug:1 [root@uw000140 ~]# egrep -c " write error to: Broken pipe" /var/log/amanda/amandad/amandad.201710040* /var/log/amanda/client/DailySet1/*.201710040* | egrep -v ':0$' /var/log/amanda/amandad/amandad.20171004004901.debug:2 /var/log/amanda/amandad/amandad.20171004005007.debug:12 /var/log/amanda/amandad/amandad.20171004005033.debug:14 /var/log/amanda/amandad/amandad.20171004005055.debug:1 /var/log/amanda/amandad/amandad.20171004005250.debug:1 /var/log/amanda/amandad/amandad.20171004005346.debug:8 Regards, Henrik -- Henrik Johansson E-mail: henrik.johansson.k...@mail.se Voice:+46 924 50129 Mobile: +46 70 555 9998 S Prästholm 799, S-955 91 Råneå, Sweden
Re: Restore with a different dumptype
Am 2017-10-04 um 16:08 schrieb Matthias Teege: > Hello, > > is it possible to create backups on node "A" with dumptype "A" and > restore on a different host with dumptype "B"? The problem is, that host > "A" uses some special tools which are not present on node "B" so I have > to use another dumptype for restore. Show us the difference and we can tell you more. I mean "show the 2 dumptypes". You can always override the dumptype via "-o" commandline option, for example. I assume you talk about using amrecover? man 8 amrecover : read "Configuration override" Stefan
approaches to Amanda vaulting?
We are in the process of adding vaulting to our existing Amanda environment, and I am curious to hear/see how other sites have approached this. In particular, I'm curious what policies you have adopted for what gets vaulted, and how exactly you have scripted the vaulting so that you are sure the correct dumps always get copied the correct number of times, etc. In our situation, our nightly backups are to vtapes on a large internal drive, and our plan is to then vault to separate vtapes on external USB drives that are rotated physically each business day. So I think we don't want to use "vault-storage", since we want to let the nightly dumps proceeded without concern for whether the next USB drive is available yet. But what isn't clear is the best way to code a cron job to run later in the day, so that it keeps track of which of the nightly dumps have already been vaulted v.s. the ones that still need to be. But more generally, I'm just curious to see how various sites have implemented vaulting. Thanks. Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Restore with a different dumptype
Hello, is it possible to create backups on node "A" with dumptype "A" and restore on a different host with dumptype "B"? The problem is, that host "A" uses some special tools which are not present on node "B" so I have to use another dumptype for restore. Thanks Matthias
