[Box Backup] Restore & Compare Issue ** UPDATE **

[Matt Brown]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Chris,

>> Well I ran the command and this was what was returned:
>>
>> root@io:/tmp# dd if=/dev/zero of=/tmp/bigfile bs=1M count=4k
>> 4096+0 records in
>> 4096+0 records out
>> 4294967296 bytes (4.3 GB) copied, 60.7408 seconds, 70.7 MB/s
>
> OK, so it's not a problem storing 4 GB files on your /tmp drive. It  
> must be a bug in Box Backup restore, as far as I can tell. I will  
> investigate as soon as I have time.
>

Ok, that would be cool - I am happy to test any patches etc if that  
helps you ?

>> In relation to the rsync of the actual file(s), the only way we  
>> are able to do that is if the Server that is running SQL Server  
>> 2005 (I am no windows expert, this is second hand) is told to  
>> disconnect the Database so we can rsync the actual SQL DB File(s)  
>> and then reconnect to it again afterwards - however because this  
>> is in a cluster environment, I am told the SQL Server would think  
>> SQL Server has failed or stopped and would fall over to the other  
>> SQL Server :( - therefore an automated backup is preformed each  
>> night using SQL Server or NT Backup to create this one large file  
>> - once this has been created we simply use Rsync to shift it over  
>> to the storage array.
>
> How about not gzipping the file before transferring it, and turning  
> of compression in MS Backup?
>

Well the file that is produced on the MS box is not gzipped until it  
reaches the storage array - it is once here we gzip and BB it to the  
offsite BBServer.

>> In addition, I was under the assumption that BB will use available  
>> soft/hard space available on the server and once this is close to  
>> full housekeeping would free up space. Currently we are only  
>> keeping about 7 days of backups of this file offsite - we have 3  
>> months + in house if we needed to roll back plus transaction logs.
>
> Yes, this is true, but you would be able to store a lot more  
> history on the Box Backup server if the diffs were smaller. The  
> best way to achieve this is to back up uncompressed files, as far  
> as I know (especially if they are large files which change  
> regularly, which seems to be the case here).
>

In addition Chris, I am not sure wether its just we have the  
directories in the wrong place but am also seeing this issue:

root@io:/root/bin# /usr/local/bin/bbackupquery "compare -aq" quit
Box Backup Query Tool v0.10, (c) Ben Summers and contributors 2003-2006
Using configuration file /etc/box/bbackupd.conf
Connecting to store...
Handshake with store...
Login to store...
Login complete.

Type "help" for a list of commands.

WARNING: Quick compare used -- file attributes are not checked.
Local file '/data/mars/CoreSystem_backup_200704142000.tar.gz' does  
not exist, but store file '/venus/ 
CoreSystem_backup_200704142000.tar.gz' does.
Local file '/data/mars/CoreSystem_backup_200704152000.tar.gz' does  
not exist, but store file '/venus/ 
CoreSystem_backup_200704152000.tar.gz' does.

[ 0 (of 2) differences probably due to file modifications after the  
last upload ]
Differences: 2 (0 dirs excluded, 0 files excluded)
Logging off...
Session finished.

However inside the /data/mars directory I have:

root@io:/data/mars# ls -alh
total 7.5G
drwxr-xr-x  2 root root  160 Apr 16 20:00 .
drwxr-xr-x 11 root root  264 Mar 28 11:39 ..
- - -rw-r--r--  1 root root 3.8G Apr 15 20:29  
CoreSystem_backup_200704142000.tar.gz
- - -rw-r--r--  1 root root 3.8G Apr 16 20:29  
CoreSystem_backup_200704152000.tar.gz

Any pointers ?

Regards

Matt Brown
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD0DBQFGMIDf6vWewLkSmagRAnqvAJMEIxEiSL+p1WXCC9oPj01hm40sAJY0tRk/
TnshTM0MqPTNcQ0bRIIG
=0sqk
-----END PGP SIGNATURE-----