Different backup size in metadata taking scheduled vs manual backup

[Papow]

OS Name/Version: Debian GNU/Linux 12 (bookworm)

Product Name/Version: AMP Release “Callisto” v2.5.0.14, built 14/06/2024 03:45

Problem Description:

Taking a backup from a schedule, compared to manually creating a backup, produces different backup sizes in backup metadata. This shows on the WebUI console as one backup being much larger than the other.

It appears that a manual backup file size is calculated as the uncompressed, while scheduled backup file size is calculated as compressed.

Here I have 2 backup examples, one as schedule (CreatedAutomatically: true), and one manual (CreatedAutomatically: false). Notice the difference in file size, while on disk they are similar size.

# Backups.json
  "ea2aa597-1aaa-458f-8889-d3ef38294dcc": {
    "Id": "ea2aa597-1aaa-458f-8889-d3ef38294dcc",
    "ParentManifest": null,
    "Timestamp": "2024-06-17T08:00:00.2359Z",
    "ModuleName": "GenericModule",
    "TakenBy": "SYSTEM",
    "CreatedAutomatically": true,
    "Name": "Scheduled Backup",
    "Description": "",
    "META": null,
    "TotalSizeBytes": 478992395,
    "Sticky": false,
    "SourceOS": 2,
    "StoredLocally": true,
    "StoredRemotely": false,
    "RemoteStoreId": null
  },
  "1719bba3-b4d3-4888-bcb9-a92e467de499": {
    "Id": "1719bba3-b4d3-4888-bcb9-a92e467de499",
    "ParentManifest": null,
    "Timestamp": "2024-06-17T17:13:27.347771Z",
    "ModuleName": "GenericModule",
    "TakenBy": "admin",
    "CreatedAutomatically": false,
    "Name": "Manual",
    "Description": "",
    "META": null,
    "TotalSizeBytes": 1996001259,
    "Sticky": true,
    "SourceOS": 2,
    "StoredLocally": true,
    "StoredRemotely": false,
    "RemoteStoreId": null
  }

## compressed on disk
# du -hs *ea2aa597* *1719bba3*
457M    20240617-080000-ea2aa5971aaa458f8889d3ef38294dcc.zip
447M    20240617-171327-1719bba3b4d34888bcb9a92e467de499.zip

## uncompressed on disk
# mkdir 1719bba3 ea2aa597
# (cd 1719bba3; unzip -q *1719bba3*.zip)
# (cd ea2aa597; unzip -q *ea2aa597*.zip)
# du -hs 1719bba3/ ea2aa597/
1.9G    1719bba3/
1.9G    ea2aa597/

Steps to reproduce:

• Run back through schedule
• Run backup manually
• Observe difference in filesize in metadata
• Observe similar filesize on disk (compressed and uncompressed)

Actions taken to resolve so far:
N/A

[Mike]

Do your logs for this instance show any orphaned backups when it was started?

[Papow]

Nope. I see a single log entry around that timestamp, and that’s it.

AMPLOG 2024-06-17 16-59-55.log:[17:13:27] [FileBackup:admin Activity/15] : Creating Backup: Manual

I also grep’ed for “orphan” (case insensitive) and see nothing going back.

To be thorough, I ran another manual backup and tailed the log file in AMP_Logs, only single new log entry for creating the backup (and still shows the uncompressed size in the Backups.json and WebUI).

[Mike]

Looks like it’s nothing to do with scheduled v.s. manual backups and AMP was (upon startup) simply using the zips file size rather than the manifest file size. I’ve stopped it from doing this now.