1

We are backing up our ASAs and switches using some scripting. It works very well. I have noticed though, occasionally, the backups to the TFTP will come out not as plain "files" with no extension, rather .tmp files.

Curious as to the cause. I have manually confirmed, the .tmp files have always been identical in size and content of then manually backed up non-.tmp files of the same backed up device.

Why does this happen? Any way to prevent it? Is there any reason to care? It seems to happen completely at random and immediately upon creation (I have tried enabling longer sleep statements in the script to no effect).

The devices are writing the backups to a Spiceworks TFTP server. I will do some investigating on that side of things to see what's going on and if I can uncover an answer or provide more solid information. Also, I've now realized 100% of the time when backing up HP Procurve devices, the TFTP is writing them as .tmp file. Thanks

TryTryAgain
  • 1,152
  • 5
  • 22
  • 41
  • I've cross posted, don't hate me :D http://community.spiceworks.com/topic/315117-tftp-backups-occasionally-being-written-as-tmp-files – TryTryAgain Mar 20 '13 at 02:07

2 Answers2

1

This is probably related to your TFTP server software. Cisco IOS (and ASA) devices don't write a temporary file to the TFTP server, they only write the file you tell them to.

cpt_fink
  • 907
  • 5
  • 12
  • Thanks for the tip, I will investigate that side of it. I also updated the question to include the TFTP specifics...that being Spiceworks. Thanks again, I didn't even think of that. – TryTryAgain Mar 19 '13 at 09:45
0

those tmp are created by the software that receives the transfer; when the transfer is finished ok the tmp should be copied to the original file name and the tmp erased, if the transfers fails the tmp is just erased.

For some reason the TFTP receiving the file erratically does not erase the tmp file of a "supposedly" ok transfer

Pat
  • 3,519
  • 2
  • 17
  • 17
  • Yep, @cpt_fink pointed me in that direction. I've worked around it by issuing an `mv *filename* filename` command in the script, in case there is a tmp remaining. Still hoping to hear back from Spiceworks regarding the matter: http://community.spiceworks.com/topic/315117-tftp-backups-occasionally-being-written-as-tmp-files – TryTryAgain Mar 21 '13 at 22:56
  • I'd would not do that move; the tmp could be left after an aborted transfer; you should just erase the tmp but you should never assume the tmp is the file correctly received. – Pat Mar 21 '13 at 23:32
  • Just erase the tmp and do what? As I stated 100% of the time the HP backups are tmp's. – TryTryAgain Mar 22 '13 at 00:47
  • please understand, those tmp you find shouldn't be there, they really talk about some issue on the TFTP code, then you cannot consider they are valid, then if they are left there you should erase them and that's it. Try to see if they are related to the lack of ack on the last transferred TFTP block, try to see if there's a TFTP log giving some tip to pinpoint the issue, try to see if your TFTP code needs to be upgraded. – Pat Mar 22 '13 at 09:18