There are lots of ntp questions and they all have the same mistake: people using SERVER on an ntp pool and POOL on an ntp server:
server 0.rhel.pool.ntp.org
As the URL says, it's a POOL. Try
pool 0.rhel.pool.ntp.org
instead or actually use a server, not a pool ...
Furthermore, most people have a timesource in their network, most often Windows Domain Controllers. If this is true for you, why messing with external ntp servers when you could use internal NTP of Windows DC ...
Don't keep ntpdate on your server if you use ntpd!
Considering for any reasons whatsoever why your system is drifting in time, whatcha gonna do 'bout it?
When you face time issues on Linux, firstly check any virtualization system - if you use VMware/Hyper-V/Xen/KVM/Whatever - think about what really is your "hardware clock" here!?! Sometimes your "BIOS" clock is misbehaving but it is as virtual as your network card(!) so if you use VMs talk to your colleagues in charge.
Considerring the differenciation of ntpd and ntpd put in a nutshell: ntpd is "cheating" your system by slighty adding fractions of time to system time (date) until local system time is synced with whatever your time source says, whereas ntpdate sets your local time to "network time" promptly.
System time is what the command date will tell you on Linux. But there is also hwclock (needs sudo) which is indeed your hardware a.k.a BIOS clock.
For once - literally speaking - you may need to do
sudo hwclock ---systohc
to set your BIOS/hardware/virtual clock to system date - what ntpd says. If you need to do this more often, there is a problem.
I know for sure, this applies to Ubuntu, so I assume it also applies to Debian. Reason is that the system may call ntpdate in time (cron.weekly?) but when you have ntpd running, it would ususally complain! You simply can't run ntpdate when ntpd is running.
Usually, you install ntpd because it owns a drift file that enables ntpd to adjust your time smoothly but "over time" - it may add here a fraction of a second and there but not forcing to reset the time to let's say 30 seconds in the future - or even worse the past - because you can assume e.g. most databases do not like time travels at all!
And that's what ntpd is for. ntpdate - in opposite - will promptly correct any time drifts what may cause time critical application issues - ntpd on the other hand will add some milliseconds to every past second so things will get the right time "in time", not surprising any application that is deeply relying on timestaps with BIG jumps in time for- or backwards. Serious databases with serious content do rely on timestamps (e.g. mysql/postgres/mariadb).
So you see they both have different approches and can't be used together.