(1) Automatic backups of databases by the server are ordinarily distinguished by database names and dates so that prior ones are not overwritten, but as suggested above move them if you have any worry about that. Those are only a relative few megabytes at a time, <10, <200, etc., unless you have an utterly enormous database.
(2) Manual phpMyAdmin exports and manual OC admin panel System / Backup backups of databases download to your own machine, where you may need to rename them (with database and when) as soon as they're complete so that the next one in sequence doesn't overwrite it. Those do not affect file counts or bytes on the server.
(3) My best guess from what you've said is that your website has been and continues to be hacked, although I'm hypersensitized to that for the time being. I recently finished mopping up a cart installation that had obviously been and continued to be hacked with invading hordes of files which miraculously reappeared, some 40,000 with corresponding oodles of megabytes at a time, even while I condemned them and tracked down why at the same time. The questions at hand related to how entry was gained and executed, and at first the files' total counts and bytes were relatively unobvious in context of the 10,000 products offered. Watching the goings-on was necessary, and sufficient. The hackers made the mistake of reverting mistaken permissions almost as abruptly as I reset them to proper values, and replacing files almost as abruptly as I deleted them (resulting in instant declaration of war; I won). There are several extremely subtle means of entry and control WHICH HAVE NOTHING TO DO WITH OC ITSELF and INSTEAD relate to nuances of Linux, Apache, and php, which in and of themselves are secure. (Hackers are themselves examples of how making everything idiot proof prompts somebody to come up with a bettered sociopathic idiot.) There is a vulnerability in some of the other software that appears to be running normally but allowed the access to mess with something else. When I zeroed in on the entries and executions, aborting them and setting a trap were fairly quick and easy to do. In that instance the hacking was tied into a global "ring" trying (unsuccessfully) to gain critical access to the database and to use a means of brute force attack. The signatures are very subtle, but an obvious clue is whether you see ANY files that have suspicious timestamps or any nonsensical names or extensions, and ANY mistaken permissions. If you do, then immediately throw OC into Maintenance mode. (When I've had time to distill the matter enough for appropriate brevity, I'll post a summary.) See PM.
(4) I also lately found in a set of Linux virtual installations' NON-PUBLIC areas a wormhole which plows ever deeper (root-wise, grows ever higher) with replicates of a basal directory along with all of its own subdirectories and files. Gigabytes deeper (or higher). The odds are against that, but when I delved some 256+ levels deep (or high) into each of those, and found that no combination of Linux commands that I issued using putty.exe would prune the self-proliferating directory set, I had seen enough to know that proverbial Houston had a gigaproblem, and there as well as across all accounts a looming teraproblem, to fix. Initially the only reason for looking for what might be amiss was that billings for service had abruptly become absurdly more expensive for simple installations than storage and traffic should become without running a veritable military-industrial complex of software to cause and justify the billing. THAT SORT OF PROBLEM HAS NOTHING TO DO WITH OC ITSELF. (Likewise, when I've had time to distill the matter enough for appropriate brevity, I'll post a summary.) See PM.
(5) Those two means of interference did not appear in contrastingly mundane hacking of other OC installations that I've resurrected in the past couple of months. Mercifully most hackers are not particularly bright or innovative (sociopathic idiots, yes; bettered sociopathic idiots, no).
(6) In any event, use BOTH phpMyAdmin and OC admin panel to bring down the respective Export and Backup of your database(s). Pronto. Then routinely bring down an Export and a Backup (they'll differ slightly in format). For efficiency, see rph's vqmod extension at
http://forum.opencart.com/viewtopic.php ... nt#p401314, downloadable in the link there to
http://forum.opencart.com/download/file.php?id=16761 (it's graciously free and it works very well). But do not delay the initial step by detouring to install vqmod or the extension.