save into the same backupfile?


Thanks for some interesting hours

Iam trying to understand my script.

Here is a part of it:
C:\Program Files\COMODO\COMODO BackUp\CBU.exe/backup_operation /type partition /source D /compressionlevel high /destinationtype destinationtypediskfile /destinationpath “F:\arkiv.cbu” /backup_type incremental

I seem to have asked COMODO to make incremental backups into a already existing fixed backup file.

What does that mean? Is COMODO changing the backed up files that are stored inside the .cbu, or is COMODO adding new .cbu inside the existing .cbu containing the incremental backups??

This is the only text i can find on the COMODO help: “Tip: The full backup and incremental/differential backups for a same source, can be stored in the same destination backup file in .cbu format.”

Best regards

COMODO Backup will be appending new backups to the existing cbu file.


Thanks Emauel.
Why i ask is that the script after the first backup, often but not always, generates a backupfile that is double the size of what is backed up. Something seems wrong.
Best regards

Maybe the disk sometimes is defragmentated. This can cause the backup size to get considerably higher.
To be sure, when this happens, take a look in restore step 2 in snapshot lists to see how many snapshots it contains, then for each snapshot, look in restore step 3 to the uncompressed size of each snapshot.

If possible, please post the uncompressed size for each snapshot in the backup.


I dont have an example on that with the script above, but here is another script that gave the same problem

C:\Program Files\COMODO\COMODO BackUp\CBU.exe/backup_operation /type partition /source D /compressionlevel high /destinationtype  destinationtypediskfile  /destinationpath "F:\Partition_C_inc_part" /backup_type incremental /diskusage high /processorusage high /scheduleTask /schedule_mode Manual /silentRun /log 

The script has generated three snapshots over time backing up a disk of 59 gb.
Snapshot 0 =34,5 gb orig 62,3 gb
Snapshot 1 =12,6 gb orig 20,2 gb
Snapshot 2 =33,3 gb orig 60,3 gb
Total 80,4 gb

The incremental doesnt seem to work, not even in snapshot 1; havent changed that much on that disc.

I use an external usb-disc to store the cbu’s.

What could be wrong…

Now i made a new backup 15 seconds after the first one was completed. The result was a snapshot of 190 mb size. But really nothing was different between the two points of backup. And still 190 mb…

Is that normal?

The backup is performed at sector level.
If the volume is defragmentated, although nothing changes from user perspective, on physical disk level sectors are shifted from one side of the disk to another, so here is a possible cause of the issue.
Another cause could be pagefile.sys which is used by Windows for paged memory. Whenever windows pages memory, it writes data into pagefile.sys, which is then flushed to disk. This can explain the 190mb difference.

A solution is to use files and directories backups instead of sector-by-sector partition backup.


OK. Thanks for an interesting piece of program by the way. Dont forget that i appreciate it.
I will come back to the 190 mb.

But what about the 20 gb. Or the 60 gb?!

I do find this interesting and do have a good time, and do thank you for a good program.

Best regards

By the way, the defragmentation level is 0% and 1% on the other disc. So that is not a problem.
Best regards

So the response fro the experts of COMODO is:

  1. You might have a defragmentaion problem.
    My answer - no i have not.

  2. Te pagefile system might give you a difference between the two times of backup in size of 190 mb in backup file though nothing has happend.
    My answer: OK but what about the 20 gb file difference. Or the 63 gb difference? We have an other problem here.

Please. I understand if you cant get the match between the question and the non profit IT specialist answering the question right in the first try, but this question could be matched better.

Best regards

The easiest way to investigate the issue would be if you could provide us the backup file. But since it’s very large I’m not sure this can be achived.
We will investigate this issue. It might take a little more time until we can provide a definitive answer.