I have installed DiskSync on my server and it works great for small backups.

When I try to configure a large backup (20GB) the job times out and I get no backup. The first response to the ticket suggested I backup a compressed file, which would preclude file level restore capability, not get a hug benefit if backups are already being compressed, and probably blow the incremental backup strategy (assuming the unit of atomicity is the file - I doubt DiskSync is doing block level incremental of partial files).

Has anyone else had this experience? I find it hard to believe that 20GB would be too much for a commercial grade backup product (actually, my first attempt was 40GB, I tried 20GB after being told of the timeout).

One question to The Planet - if your people can't resolve this issue, do you escalate to e-vault or just tell the customer that large backups are not supported?

Also, the FAQ states that over limit usage is billed but when I inquired about the service I was told the system would enforce a hard cap and not let me run over.

Hopefully, a Planet person can answer these. DiskSync looks like a well done, professional grade solution - if I can only get it to work on a production sized system.

We have backup sets that take up more than 20 GB so that sounds like an error. As far as we can tell you should be able to back up over 20 GB.

I'm sure Justin (the backup group manager) will respond to this thread.

In the past they have been real good about working out any issues that we have had.

Rob,

I would be interested to see the ticket where it was recommended that you back up a compressed file instead of the files from your filesystem.

Technically, it would not break the delta change incrementals so long as that compressed file was handled correctly. DiskSync will see it as a new file even if it has the same filename unless the file is truncated to 0 bytes and then appended with the new data. Still, this isn't recommended.

There should be no reason why 20GB of data would cause a problem.

There is one case wherein the "deferring window" may be exceeded, but inside our datacenter that shouldn't happen with 20-40GB backup sources. Even still, when the deferring window is reached, the next backup resumes by first collecting changes to files it picked up in the first backup, and then continues picking up files that have not yet been collected. I'm not sure if the way I wrote that makes much sense. Let me know if not, and I can elaborate.

Judging by your comments, it sounds as if there is an error occuring that is causing the backup to fail, not just time out the deferring window setting.

Large backups are quite well supported. I have several systems that backup several TB with DiskSync.

There is no "hard cap" on DiskSync, it will not corrupt and/or abort your backups as DiskSync itself has no comprehension of a limit or subscribed amount. Whomever responded to your query was confusing DiskSync and NAS Backup, the latter of which has a hard quota on byte storage.

I will try and dig up your account information in Orbit. If you do not receive a ticket update from me shortly, please PM me your info and I will dig into this for you.

Thanks!

Sir,

I found your account information and the ticket specific to this issue. I have update therein to notify you as to what we are observing and the steps we are taking to diagnose the situation.

For our other readers benefit, this is an abnormal situation. Even with the large number of DiskSync services we provide, there are very few instances such as this. We are working with the customer and will involve the vendor if required.

As always, we are committed to resolving customer issues with our services, and I am glad this issue was brought to my attention. We have escalated the priority on this case, and hope to have resolution to the issue shortly.

Thank you for hosting with The Planet!

Just to let everyone know - the response I am getting from The Planet on this issue is nothing short of fantastic!

$2/GB isn't cheap, but with service like this, it's a bargain.

Thanks for the compliment, Rob.

I apologize it took a little longer than I would have personally liked for us to find the cause of the problem. Hopefully the proposed resolution will be acceptable and should cure the issue you've been experiencing. This was a little unexpected, and FYI I've notified the vendor's development team to ensure they're able to handle that sort of situation in a future release without causing the sort of error you experienced.

Solution appears to have worked.

It was a classic "code did not handle special characters properly" problem. I unintentionally had a directory named " (yes, just ") and that was causing fault in the prescanning phase.

Rob:

Glad it all worked out.