I can't swear, but I guess this is a Pmail thing. I do use Cobian Backup but never used its shadow copy facility. It needs .Net framework which I'm not willing to run on my machines. So, making long story short, I never used this feature and have no plans to do so.

What I think may be the cause of your problems is synching Pmail files. Pmail files are in constant change and each of them entitles a file to be synched to host. For example, a 2GB folder file (PMM/PMI pair) under synching will produce weird results. It most likely will have a 2GB .PMM file and only a 229KB .PMI index file. For each we have different writing time as well as transfer time. We can also have at backup host, at a given time, an index that do not belong to correspondent folder data. That said, I'm positive cloud synching should be avoided, at least in this scenario.

OTOH backup is different. You shut down the application and save its files to a local or remote repository (Cobian Backup handles this easily). You can save backup locally and then synch its files or transfer backups (full, incremental, or differential) directly to cloud host. This has been working well here for uncountable years. :)

On another thread, Euler GERMAN repeats the old warning:

[quote user="Euler GERMAN"]

read/write access to its files. If you're going to backup any or all of

its files and folders you must shutdown Pegasus Mail first. This is the

same reason why Pmail also complains about real-time antivirus activity.

Try to make

your Pmail backup in batches. I do daily backups using a free tool from

Luis Cobian called Cobian Backup. ... Cobian Backup takes care to have Pmail shutdown prior to

initiate backup, and starts it up when it finishes. Tasks can be either

scheduled or on demand so it won't interfere or interfere as little as

possible to Pmail activity.

But is this true for all modern continuous on-line backup systems, that uses new advanced techniques like Volume Shadow Copy Service etc. Do they all interfere with Pmail?