Size Discrepancy

Hello,

First post. Hope to begin contributing. My TeamViewer ID is: [just kidding]. Couldn't resist.

So I've been struggling with the Cloud Backup solution. I have a server that I've been trying to backup about 350 GB of data. At first it couldn't handle backing up live SQL Server files. Constantly failed for a couple weeks. Not too surprised about that honestly, with files that are 34 GB and constantly being changed, and the backup taking over a week. Contacted support and they said they were working on a database solution for that very reason. So I deleted the bad backup by uninstalling it from the server, reinstalled it, excluded the mdf/ldf files entirely and created a backup schedule on the server to create SQL Backup (BAK) files in a temp directory. The local SQL backup begins every weekday at 6 PM and it finishes in a little over an hour. TeamViewer Cloud Backup begins every weekday at 10 PM, to give the SQL backup more than enough time to finish on it's own. I received two failure notices, but I finally have a successful backup (suposedly).

I'm concerned about the size discrepancy between the real file size (right) and the size TeamViewer reports (left). I read nothing about compression in any of the documentaion or community and I would expect the true file size to be reported, or at least some note that the advertised size is a compressed size. Checking other small, non SQL Server backup, files also appear to be compressed.

backup size.jpg

Is that what's happening here? Are the file sizes shown in TeamViewer's MC compressed sizes on AWS?

Also, is there any documentation on the checks in place for the backup so I can feel comfortable that data is in fact being backed up? With all the failures I've experienced and the difference in file size I'm concerened. For example, does TeamViewer Cloud Backup perform a checksum of the uloaded file and the local file to ensure an exact match?

Find more posts tagged with

Comments

Vatsilidis

Hi @TotalPC

I am not an expert on the TV backup service, but I know very well that most of the backup services and standalone applications are using file compression algorithms on the data, in order to make use of the same data in less space and to use less internet bandwith usage.

Of course almost every case these are using copy confirmation algorithms to verify the correct data transportation.

I would suggest you do one smart test and see the compression ratio with that. If you upload a big file o text it will have a big compression ratio for sure. But if you upload an already compressed file, like many jpeg pictures inside to a .rar or .zip file, then because jpeg is using high ratio compression algorithms, it is very logical to see a very small change to the size of this file, after upload it to the backup service, and thus because it could not be compressed more!

Best regards