I/O-errors:
HTTP does not know incremental uploads. All writes to a file in davs2 will go into the cache and only when the file is closed davfs2 will upload the file.
Because of this network problems can only cause an I/O-error when

• You open an existing file
• you create a new file and use locks
• you close a file with option "delay_upload 0" set.

But all versions up to 1.5.0 have a bug and don't return an I/O-error on close even with delay_upload 0. This bug is fixed in version 1.5.1 (which is in Debian Testing).
I don't know whether I/O-errors on close will  be of much help. Applications might just ignore them.

Corrupted files:
It is not clear to me. My assupmption: There are your files that you want to back up. Davfs2 will probably never see this files.
There are the "chunks" created by Obnam. This will be the files seen by davfs2.

With this assumption:
davfs2 will upload files with HTTP-method PUT. It will only consider an uplad as successfull when it gets a proper staus code back from the server. Network timeouts will be considered as temporary failures. In this case davfs2 will just hold the file in the cache and retry uploading with increasing time intervals. This also works if the file system is unmounted and mounted again.
But when uploading fails more often than "max_upload_attempts" times then davfs2 will consider this a permanent failure. The file will then be moved into the lost+found directory.
Most probably the corrupted files are caused by missing Obnam chunks. You should find these chunks, with some random string appended, in lost+found.

To increase the chance to notice network failures you may

• use locks even when you don't need locking
• install davfs2 version 1.5.1 or 1.5.2

To increase the chance that files don't go into lost+found but are uploaded after the network is operable again:

• increase max_upload_attempts
• increase max_retry
• be patient.

Other reasons for corrupted files:
Corruption may also be caused by errors in the upload process. But this is not very likely and I would only consider it when other explanation prove wrong.

General remark:
I still think that davfs2 is usefull to allow applications without support for WebDAV to access WebDAV-resources like a regular file system.
But this will never be as good as a "real" file system. There is simply no 1:1 relation between the WebDAV-protocol and file system operations.
Now I notice that many people try to use some Webspace for backups, using davfs2. You cold make more of WebDAV if the Backup application would use WebDAV directly without that imperfect file system layer in between. Maybe the developer of Obnam is open for that idea. (With some help, but at least for the next year I am not able to do any serious work on this). The Neon library used by davfs2 was - as far as I know - intended for use cases like this.

Werner