Aloha POS trans.log overwritten, no mirrorlog to be found 2

[RoRoBun]

I am hoping someone can give me some insight on a situation that I fully do not grasp.

Basically I work for a restaurant that uses Aloha POS, they outsource help from a POS company to help manage the equipment. Yesterday I was told the system went down in one of our out of town restaurants and it took them a while to narrow the issue down to the BOH server. Anyway, the site was in redundancy for most of the AM and after lunch the outsourced company attempted to take them out of redundancy. It worked and everything was up and running but none of the AM sales/clock in's, ect were able to be found. I was then told by this outsourced company that the trans.log containing the AM data had been over written. My question is how does the trans.log get initially created and how would taking them out of redundancy over write previous data? Can the data be recovered? In the 12 years we have been using Aloha Pos this has never happened and I understand there is the possibility of a mirror.log existing but the company said they are unable to locate it. Thank you in advance for any advice/light on the subject.

 

[MenulinkMan]

I've pulled sites in and out of redundancy without issue before. The 2 scenarios that come to mind:

1. The reseller/tech deleted the trans.log. I've had this happen, and there is nothing you can do.
2. There might be some incorrect permissions dealing with /bootdrv or someone mucked with downtime.ini.

I tend to lean towards reseller error or permissions.

On a normal day, the trans.log is created on the fileserver and copied to the terminals during the bootup / sync. The only time that a terminal would create a new trans.log is if the master term is acting as the file server/redundancy.

 

[AlohaRoss]

I have never had a system pulled from redundancy correctly and loose the trans.log. As part of the file server recovery it looks for the trans.log on FOH and copies to BOH. You may look in your data folder and see if they renamed the trans.log to something else.

The only other way to get of redundancy would be to delete downtime.ini from all foh machines and them log them all off and back on. In doing so they would then sync the trans.log from the BOH. If they had not copied the trans.log from FOH to BOH prior then the FOH will now have a trans.log that has nothing to do with any sales or labor from that day. I would look to find a more experienced outsourced Aloha support company if you dont want to deal with NCR. there are many of us out there.

AlohaRoss

http://www.needaholahelp.com

spelled like Aloha but NCR won't let me use Aloha in my domain anymore

 

[RoRoBun]

Wow, Thank you so much for the insight!! This was extremely helpful with getting an idea of what more likely happened to that file. You both are the bomb!