The context - So I am an intern (So I'll appreciate a more noob friendly response) and we have several websites on a server of which we do a backup daily, at midnight. We use MongoDB and there's a cron job with a script which does a mongodump to a temp dir on the server, the contents of which are then rsynced onto a remote backup server and the temp dir is deleted. We have several websites on there. The database of each is around 2GB, with the exception of two websites with a DB for 4GB and 5GB respectively. In total, all databases are about 23-24GB. There is also a completely separate server with only one website with about 100GB database.
The problem - We monitor our websites using Pingdom and New Relic and each night, during the backups, we get alerts for both servers. The logs don't say much, so I'm guessing they didn't go down completely, just became very very slow. Haven't observed it myself on any of these websites, but I have on a stage website when taking a manual backup. It did come to a crawl.
I am told this didn't used to happen before, even though the way we're backing up hasn't changed, since I came here. I'm guessing, that's because DBs are now larger or there's more of them.
The question - Is there a way to make the whole backup process more performance efficient, so the servers don't go down or come to a crawl?
My ideas - I've been reading about compact and was wondering if you think this would help? I'll probably try it on the stage servers first. Also, is there any way to not write the dump to a temp dir first, but instead to put it directly on the remote server? I'm hoping this would reduce the I/O operations on the live server and improve performance, though I can't seem to find a way to do it.
Some advice will be greatly appreciated, as the project manager is crying about the servers going down at night.