# Filebeat too quick on recovering data **URL:** https://discuss.elastic.co/t/filebeat-too-quick-on-recovering-data/241133 **Category:** Beats **Tags:** filebeat **Created:** [July 14, 2020, 12:41pm UTC](https://discuss.elastic.co/t/filebeat-too-quick-on-recovering-data/241133 "2020-07-14T12:41:19Z") **Posts on this page:** 1 **Showing post:** 3
### Author: ![Bader](https://avatars.discourse-cdn.com/v4/letter/b/13edae/32.png) [@Bader](https://discuss.elastic.co/u/Bader) #### Post date: [July 15, 2020, 11:12am UTC](https://discuss.elastic.co/t/filebeat-too-quick-on-recovering-data/241133/3 "2020-07-15T11:12:49Z")
Hi Chris! Thanks for your reply. Unfortunately, our infrastructure is kinda complicated, and these logs are somewhat critical when monitoring our systems, so placing limits may cause some performance issues on live logs which will be a problem. I may look into playing with the Logstash filter to throttle differently depending on the log file name (if that's possible to compare the date in the logfile name to the current date but that's not a discussion for here I assume). Anyways thanks for the suggestion! Added this Logstash issue to track this: 3 > [@Logstash filter basted on log file age](https://discuss.elastic.co/t/logstash-filter-basted-on-log-file-age/241350): > > Hello. I am running ELK 6.6 on a CentOS 7 box. I have filebeat configured on a Windows machine to forward specific logs to Logstash. The problem I have is that my Logstash filter has a throttling mechanism setup as to not overwhelm the ELK box when live data is being shipped on a production system. However, if (and this happened) filebeat was down, then when restarting it is expected to ship the old files that it hadn't. Filebeat does do this but the problem is that it processes the logfile ve… --- _[View the full topic](https://discuss.elastic.co/t/filebeat-too-quick-on-recovering-data/241133)._