How Salesforce calculates an org size can be dramatically different from how large the actual backup will be. Similarly, two 1TB orgs can take dramatically different lengths of time to back up, based on the actual org size.
That is however, exactly what we would expect to see. This is because Salesforce count most record sizes as 2K (There are some exceptions e.g. EmailMessage records that are larger). We count the actual data usage, therefore, there may be a difference in sObject sizes in Salesforce and us.
Salesforce uses several proxies to calculate storage, According to this article it considers most records to be 2K in size per this article. Some exceptions include:
The article also has a number of caveats that should be review to understand rounding and how it is a proxy for actual storage
The main impact is that according to this article, only the following records are counted against storage:
Most notable is that all child objects of standard objects do not count. This is addressed in this community post.
“Opportunity line items do not count against storage quotas. Anything that does use storage space would be listed on the Storage Usage page in your org, and also would be listed on the Storage Usage help topic linked in the original question. If opportunity line items did consume space, that document page would explicitly call out that fact. One important rule to remember regarding salesforce.com documentation is that anything not mentioned doesn't exist or doesn't apply. Omissions in the documentation are always intentional.”
This is where an org can be MUCH larger than is represented on the Storage Usage page. For example, “Assets” which is a child object of accounts (or contacts) does not count towards storage. A recent prospect had millions of assets in their system. This highly used object almost doubled the size of the org from 1.2 TB to 2.2 TB.
Some other objects that do not count toward storage are: