Re: [BackupPC-users] BackupPC_tarCreate generats corrupted file listings (ver 3.1.0)
John, I am seeing corrupted directory listings using BackupPC_tarCreate. One of the reported filenames has a bunch of nulls in the middle of it using BackupPC-3.1.0. I'd like to get to the bottom of this. Let's take this off list. It would be great if you could get this to happen on as small an archive as possible, and if possible to email to me (I'm hoping you can make it happen on non-confidential files, ideally existing open-souce public files). If I can't replicate it I will propose some additional debugging code you could run. Craig -- ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List:https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki:http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
[BackupPC-users] BackupPC_tarCreate generats corrupted file listings (ver 3.1.0)
Hi all: I am seeing corrupted directory listings using BackupPC_tarCreate. One of the reported filenames has a bunch of nulls in the middle of it using BackupPC-3.1.0. I am doing a new BackupPC install and as part of the testing phase I verify backups using: BackupPC_tarCreate -l whose output is compared against a find to see if any files are missing. I also use BackupPC_tarCreate | tar --compare to validate the data. The file that is incorrectly listed seems to verify ok as far as I can tell. While running the verification procedures for BackupPC as we move it to new box, I came across this problem: Using: sudo -u backup /tools/BackupPC/bin/BackupPC_tarCreate -h ops03.example.com \ -n -1 -l -s /var/www/html/cacti .| less I see: [normal listing] ./lib/adodb/drivers/adodb-informix72.inc.php ./lib/adodb/drivers/adodb-ldap.inc.php ./lib/adodb/drivers/adodb-mssql.inc.php ./lib/adodb/drivers/adodb-mssqlpo.inc.php ./l...@^@^...@^@^...@^@^...@^@^...@^@^...@^@^...@^@^...@^@^...@^@^...@^@^...@^@^...@^@^...@^@^...@^@^...@^@^...@^@@^...@^@^@ [a ton more null characters] ^...@^@ib/adodb/drivers/adodb-mysql.inc.php ./lib/adodb/drivers/adodb-mysqli.inc.php ./lib/adodb/drivers/adodb-mysqlt.inc.php I found this when comparing the files list produced by BackupPC against the list generated by find on the same backup share. The nulls show up in less as well as od -c. Using -L rather than -l to getthe listing has the same issue but 40 lines later: 100644 109/1091935 ./lib/adodb/lang/adodb-pt-br.inc.php 100644 109/1091895 ./lib/adodb/lang/adodb-ro.inc.php 100644 109/1091954 ./lib/adodb/lang/adodb-ru1251.inc.php 100644 109/1091828 ./lib/a...@^@^...@^@ [...] ^...@^@^...@^@^...@^@^...@^@^...@^@^...@^@^...@^@^...@^@^...@^@^...@odb/lang/adodb-sv.inc.php 100644 109/1092002 ./lib/adodb/datadict/datadict-access.inc.php 100644 109/1093936 ./lib/adodb/datadict/datadict-db2.inc.php 100644 109/1093789 ./lib/adodb/datadict/datadict-firebird.inc.php 100644 109/1092514 ./lib/adodb/datadict/datadict-generic.inc.php Looking at the first directory in question doesn't show any nulls: sudo ls /backup-pc/pc/ops03.example.com/14/f%2fvar%2fwww%2fhtml%2fcacti/flib/fadodb/fdrivers | cat -v attrib fadodb-access.inc.php fadodb-ado5.inc.php fadodb-ado_access.inc.php fadodb-ado.inc.php fadodb-ado_mssql.inc.php fadodb-borland_ibase.inc.php fadodb-csv.inc.php fadodb-db2.inc.php fadodb-fbsql.inc.php fadodb-firebird.inc.php fadodb-ibase.inc.php fadodb-informix72.inc.php fadodb-informix.inc.php fadodb-ldap.inc.php fadodb-mssql.inc.php fadodb-mssqlpo.inc.php fadodb-mysqli.inc.php fadodb-mysql.inc.php fadodb-mysqlt.inc.php fadodb-netezza.inc.php fadodb-oci805.inc.php fadodb-oci8.inc.php fadodb-oci8po.inc.php fadodb-odbc.inc.php fadodb-odbc_mssql.inc.php fadodb-odbc_oracle.inc.php fadodb-odbtp.inc.php fadodb-odbtp_unicode.inc.php fadodb-oracle.inc.php fadodb-pdo.inc.php fadodb-postgres64.inc.php fadodb-postgres7.inc.php fadodb-postgres.inc.php fadodb-proxy.inc.php fadodb-sapdb.inc.php fadodb-sqlanywhere.inc.php fadodb-sqlite.inc.php fadodb-sqlitepo.inc.php fadodb-sybase.inc.php fadodb-vfp.inc.php Using od -c in place of cat -v doesn't show any null characters either, so the listing issue isn't a result of some wierd form of filesystem corruption AFAICT. Anybody have any idea what's happening here? Anything I can flip on to get better debugging to get this fixed? This could be a 64 bit issue as all the prior backuppc installs I have done are 32 bit, but this newer box is also handling more data as as well so Some vital stats: OS: centos 5.2 BackupPC version: 3.1.0 uname -a: Linux ops03.example.com 2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 11:57:43 EST 2008 x86_64 x86_64 x86_64 GNU/Linux filesystem: ext3 on a raid 6 array: /dev/md1 4.5T 462G 3.8T 11% /disk/md1 tune2fs -l on device: tune2fs 1.39 (29-May-2006) Filesystem volume name: none Last mounted on: not available Filesystem UUID: 83165372-7c6b-4fdf-804e-e474df128a45 Filesystem magic number: 0xEF53 Filesystem revision #:1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file Default mount options:(none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 1220968448 Block count: 1220966208 Reserved block count: 61048310 Free blocks: 1124763690 Free inodes: 1218526277 First block: 0 Block size: 4096 Fragment size:4096 Reserved GDT blocks: 732 Blocks per group: 32768
