Support

The difference in the file size reported by Akeeba Backup, your hosting control panel and FileZilla has to do with the definition of Kb and Mb.

Akeeba Backup uses the IEEE (base-2) definition of Kb and Mb. One Kb is 1024 bytes and one Mb is 1024 Kb (1048576 bytes). Most applications use the SI (base-10) definition where one Kb is 1000 bytes and one Mb is 1000 Kb (1000000 bytes). This is a 4.63% difference in the reported sizes when using base-2 vs base-10 units (or vice versa). If you add 4.63% to 280MiB (base-2 units) you get 292.964Mb (base-10 units). So both displays are right!

Confused? It's the same thing with hard disks. Hard disk manufacturers report the size of HDDs/SSDs in million bytes (base-10) while most operating systems report it in base-2 units. That's why a 512Gb HDD is only 489Gb unformatted. Yeah, it's extremely confusing, I'll give you that. More so when you get SSD sizes in base-2 units, HDD sizes in base-10 units, file sizes on the web in any unit, file sizes on your computer in base-2 units and so on and so forth and... Oh, dear Lord, we geeks suck at defining standards as humorously illustrated in this XKCD comic.

As for the problem you had, we do have documented that you are supposed to use an FTP/SFTP application in Binary file transfer mode to download the backup archives correctly if they are a bit big. This "a bit big" is intentionally vague. On most servers "a bit big" is anything over 100Mb or so, on some servers it's far less (even 5Mb!) or some others it's over 1Gb. It depends on multiple factors including PHP memory limit, PHP mode (mod_php, FastCGI), Apache configuration, server speed, your download speed, even your browser make and version. Since the download through the browser depends on so many factors we recommend ALWAYS using an FTP/SFTP client in binary transfer mode and then check the file size in bytes. The size of the downloaded file IN BYTES must match the size of the file on your server. If they don't match your archive is corrupt and will fail to restore.