Okay, the whole deep sleep thing needs you to take a totally different approach, and to break all the Blynk rules about a clean void loop and the use of timers.
I’m guessing that previously your process was borderline, and then (for some unidentified reason) this no longer worked. This could be to do with your ISP, power supply or router, or because the ESP was feeling uncooperative 
It’s important to allow the write to the Blynk server to complete before the device goes back to sleep, and I always like to put a Blynk.run in there before the deep sleep command.
@christophebl and I did quite a bit of work on a project of his which involved deep sleep and he’s now take that much further.
Here’s a link to his project, which may be of some assistance in the deep sleep coding:
One issue that this project identified is that using Blynk.begin with deep sleep isn’t a good idea. If a connection tonWiFi or the Blynk server can’t be established for any reason then the device will keep trying until the battery goes flat. Much better to use Blynk.config and Blynk.connect.
It’s also better if you allocate a reserved IP address for your ESP in your router, and preferably use a (the same) static IP in your code rather than rely on a DHCP allocates IP, as it makes the re/connection time much quicker. You won’t notice this when testing and using a short sleep time, as your router will remember the MAC address of your ESP in its routing table. Once you increase the sleep time the routing table will have nbeen purged, and a slower DHCP address negotiation process will have to be done, which will bump-up your wake times and you won’t be able to figure-out why you aren’t getting a pro-rata battery life with longer sleep times.
Pete.