Common metadata size could not be read

Hi everbody,

For one system I always get this error message on file backups (incremental and full):

2017-11-14 15:40:54(error): Error saving metadata. Common metadata size could not be read.
2017-11-14 15:40:54(info): Copied metadata to /tmp/cps.lrF4x1 for error analysis

UrBackup Server 2.1.19 on Ubuntu 16.04, Client 2.1.16 on Windows 8.1

I don’t really know where to start searching…

Thanks,
K0n24d

EDIT: found some extra info in the realtime log:

14/11/17 15:40  	DEBUG  	Metadata of "ErrorInfo.ini" is missing
14/11/17 15:40  	DEBUG  	Metadata of "summary.log" is missing
14/11/17 15:40  	DEBUG  	Metadata of "20140816_141037_install.log" is missing
14/11/17 15:40  	DEBUG  	Metadata of "Royalty.ini" is missing
14/11/17 15:40  	DEBUG  	Metadata of "SRExport.ini" is missing
14/11/17 15:40  	DEBUG  	Metadata of ".." missing
14/11/17 15:40  	DEBUG  	Metadata of ".." missing
14/11/17 15:40  	DEBUG  	Metadata of "regid.1991-06.com.microsoft Microsoft Office Professional Plus 2013.swidtag" is missing
14/11/17 15:40  	DEBUG  	Metadata of "regid.1991-06.com.microsoft_Windows-8.1-Pro.swidtag" is missing
14/11/17 15:40  	DEBUG  	Metadata of ".." missing
14/11/17 15:40  	DEBUG  	Metadata of ".." missing
14/11/17 15:40  	DEBUG  	Metadata of ".symlink_java.exe" is missing
14/11/17 15:40  	DEBUG  	Metadata of ".symlink_javaw.exe" is missing
14/11/17 15:40  	DEBUG  	Metadata of ".symlink_javaws.exe" is missing
14/11/17 15:40  	DEBUG  	Some metadata was missing
14/11/17 15:40  	DEBUG  	Syncing file system...
14/11/17 15:40  	INFO  	Transferred 64.0017 GB - Average speed: 74.8309 MBit/s
14/11/17 15:40  	DEBUG  	Script does not exist urbackup/post_full_filebackup
14/11/17 15:41  	INFO  	Time taken for backing up client XXXXXXXXX: 2h 4m 3s
14/11/17 15:41  	INFO  	Backup completed with issues

post (not that it will actually help me to solve the issue , but that s all the metadata i can think of, and uroni may ask them)

du -h /tmp/cps.lrF4x1
du /tmp/cps.lrF4x1
du --apparent-size /tmp/cps.lrF4x1
stat /tmp/cps.lrF4x1
lsattr /tmp/cps.lrF4x1
getfacl /tmp/cps.lrF4x1

Here you go

25M	/tmp/cps.lrF4x1

25124	/tmp/cps.lrF4x1

25124	/tmp/cps.lrF4x1

  File: '/tmp/cps.lrF4x1'
  Size: 25726873  	Blocks: 50248      IO Block: 4096   regular file
Device: 803h/2051d	Inode: 1016        Links: 1
Access: (0600/-rw-------)  Uid: (  112/urbackup)   Gid: (  121/urbackup)
Access: 2017-11-14 16:34:52.825309132 +0100
Modify: 2017-11-14 15:40:54.279916451 +0100
Change: 2017-11-14 15:40:54.279916451 +0100
 Birth: -

-------------e-- /tmp/cps.lrF4x1

getfacl: Removing leading '/' from absolute path names
# file: tmp/cps.lrF4x1
# owner: urbackup
# group: urbackup
user::rw-
group::---
other::---

But looking at the file content and the messages I was thinking that this file is rather a dump of the metadata of the files in the backup and not a file we could not get the metadata for.

Not sure this phrase is understandable by someone else :wink:

Haa you re right.
At home the cps files i have range from 40bytes to 14MB, hence i was thinking it was copied files.

Can you send the (compressed) metadata file to bugreports@urbackup.org ?

Sorry to be paranoid. Can I decode/inspect them beforehand?

You have the same problem?

I thought theses were temp files so i never payed any real attention, but yes i also have a bunch of /tmp/cps* files on my clients. However i can t find the same error message in the client logs.

at home it s like 3 files in 2 hours
on the home server(it runs both a urbackup client and server) it s 1712 since 30 april , so maybe some cleanup is needed :slight_smile:

Hello,

I must admit that given the content of the file, I feel a little bit uncomfortable sending it out. Is there a way to only extract what you’re interested in? (I do know this might be a complicated question…)

By the way, I “solved” the issue by excluding the AppData folders from the file backups. This was not really of interest anyway for our file backups.

If you want to you can then probably track it down to some specific file(s) and only send that metadata file (or tell me what’s different with those file(s)).