Re: [BackupPC-users] removing an old backup

[Jeffrey J. Kosowsky <backuppc@ko...>]

Peter Peltonen wrote at about 13:20:36 +0200 on Tuesday, November 17, 2009:
 > Hi,
 > 
 > Reading from archives I thought this would be a proper way to remove
 > an old backup:
 > 
 > cd /var/lib/backuppc/pc/hostname/
 > rm -fr 0
 > su -s /bin/bash backuppc
 > BackupPC_nightly 0 255
 > 
 > But I still can see the backup number 0 in the web interface? How do I
 > remove it from there or am I doing something wrong?
 > 

There is a bash script written by Matthias Meyer (and available by
googling on the web).
I think called BackupPC_deleteBackup (or maybe that's just what I
called it ;)

Re: [BackupPC-users] Sudden Error during backup

[Les Mikesell <lesmikesell@gm...>]

Michael Stowe wrote:
>
>>> The first advice was:
>>>   "The first thing to verify, of course, is that smbclient can connect
>>> using the command line."
>>>
>>> That's the one that matters for smb xfers.  Can you connect with
>>> smbclient to the sharename in question with the same credentials
>>> configured in backuppc?
>> sorry, I forgot to mention that in my list. Either smb client connection
>> has been tested twice, and it works fine when invoked manually, using
>> the same credentials and shares etc.
>>
>> Best regards
>> Stefan
> 
> Bizarre!  You're saying that the command line works when you run it, but
> the exact same command line fails when run by backuppc?  This suggests
> your computer has acquired a capricious spirit -- or, something is
> actually different.
> 
> What command line are you verifying with smbclient?  Are you actually able
> to retrieve files?

It is actually a bit hard to duplicate the command exactly since backuppc passes 
the credentials in the environment so you don't see them in the logs or in a ps. 
There have been versions of samba that had problems parsing the backuppc command 
line but I've forgotten which ones.  Is there any chance that smbclient has been 
updated on the backuppc server?  And is there any difference if you force an 
incremental run instead of a full?

-- 
   Les Mikesell
     lesmikesell@...

Re: [BackupPC-users] removing an old backup

[Peter Peltonen <peter.peltonen@gm...>]

Hi,

On Tue, Nov 17, 2009 at 2:03 PM, Tyler J. Wagner <tyler@...> wrote:
> On Tuesday 17 November 2009 11:20:36 Peter Peltonen wrote:
>> Hi,
>>
>> Reading from archives I thought this would be a proper way to remove
>> an old backup:
>>
>> cd /var/lib/backuppc/pc/hostname/
>> rm -fr 0
>> su -s /bin/bash backuppc
>> BackupPC_nightly 0 255
>>
>> But I still can see the backup number 0 in the web interface? How do I
>> remove it from there or am I doing something wrong?
>
> Also remove the appropriate entry from /var/lib/backuppc/pc/hostname/backups.

This did the trick, thanks!

Cheers,
Peter

Re: [BackupPC-users] Sudden Error during backup

[Michael Stowe <mstowe@ch...>]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> Les Mikesell schrieb:
>> The first advice was:
>>   "The first thing to verify, of course, is that smbclient can connect
>> using the command line."
>>
>> That's the one that matters for smb xfers.  Can you connect with
>> smbclient to the sharename in question with the same credentials
>> configured in backuppc?
>
> sorry, I forgot to mention that in my list. Either smb client connection
> has been tested twice, and it works fine when invoked manually, using
> the same credentials and shares etc.
>
> Best regards
> Stefan

Bizarre!  You're saying that the command line works when you run it, but
the exact same command line fails when run by backuppc?  This suggests
your computer has acquired a capricious spirit -- or, something is
actually different.

What command line are you verifying with smbclient?  Are you actually able
to retrieve files?

Re: [BackupPC-users] removing an old backup

[Tyler J. Wagner <tyler@to...>]

On Tuesday 17 November 2009 11:20:36 Peter Peltonen wrote:
> Hi,
> 
> Reading from archives I thought this would be a proper way to remove
> an old backup:
> 
> cd /var/lib/backuppc/pc/hostname/
> rm -fr 0
> su -s /bin/bash backuppc
> BackupPC_nightly 0 255
> 
> But I still can see the backup number 0 in the web interface? How do I
> remove it from there or am I doing something wrong?

Also remove the appropriate entry from /var/lib/backuppc/pc/hostname/backups.

Regards,
Tyler

-- 
"Once is happenstance. Twice is coincidence. The third time it's enemy
action."
   -- Auric Goldfinger

Re: [BackupPC-users] Rsync on an image?

[Pieter Wuille <sipa@us...>]

On Thu, Nov 19, 2009 at 12:42:04PM +0100, Christian Völker wrote:
> Hi,
> 
> [I know, you don't want to have this topic again, treat it as a collection]
> 
> has somebody tried to rsync a file system image?
> 
> As my BackupPC pool is too large for any backup programm (~600GB) to
> follow all the hardlinks, I'm looking (As everyone here) for a better
> solution.
> 
> Before I waste days on testing I want to ask how you perform you backups
> of the pool.
> 
> So my question is how rsync handles large files? Let's say I have my
> file system image of 600GB. I transfer it to the remote site by USB
> disk. Now I create a new image from the pool and perform an rsync on
> these files. Assuming 1GB has changed spread over the file- how many
> data will rsync transfer? Will it start transferring from the first
> mismatched bit? Or just transfer the changed data?

Our offsite backup is implemented as an rsync of an image of an LVM
snapshot of the backup filesystem. A script issues xfs_freeze on the
filesystem to bring the on-disk form in a consistent state, a snapshot
is taken, the snapshot is mounted using a script[1] as a directory of
images (part0001.img, part0002.img, ...), and this directory is rsynced
with an offsite location (the offsite server has 2 data directories, and
rsyncing is done alternatingly to each - that way we have a valid offsite
backup even if something happends during the transfer itself, which is
done with rsync --inplace).

Splitting it in several (500x 1GiB) files allows rsync to start faster
(since it won't go looking for data matching the first GiB in the
remote other GiBs).

The scripts logs how much data-difference LVM measures, how much changed
bytes rsync sees, and how many bytes are sent on the network. LVM measures
things differently (other block sizes, blocks that are changed during each of
the two previous runs are counted twice, ...), but it seems to produce numbers
comparable to the ones rsync gives.

Overall, this procedure works very well. One synchronisation run takes
between 4 and 7 hours, and transfers on average a few GiB worth of changed
backup data. (the offsite locations are connected using a 100Mbps university
network, but rsync is rate-limited to 10Mbps)

  [1] https://svn.ulyssis.org/repos/sipa/backuppc-fuse/devfiles.pl

kind regards,

-- 
Pieter

[BackupPC-users] removing an old backup

[Peter Peltonen <peter.peltonen@gm...>]

Hi,

Reading from archives I thought this would be a proper way to remove
an old backup:

cd /var/lib/backuppc/pc/hostname/
rm -fr 0
su -s /bin/bash backuppc
BackupPC_nightly 0 255

But I still can see the backup number 0 in the web interface? How do I
remove it from there or am I doing something wrong?

Best,
Peter

Re: [BackupPC-users] Sudden Error during backup

[Stefan Jurisch <s.jurisch@si...>]

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

Hello,

Les Mikesell schrieb:
> The first advice was:
>   "The first thing to verify, of course, is that smbclient can connect 
> using the command line."
> 
> That's the one that matters for smb xfers.  Can you connect with 
> smbclient to the sharename in question with the same credentials 
> configured in backuppc?

sorry, I forgot to mention that in my list. Either smb client connection
has been tested twice, and it works fine when invoked manually, using
the same credentials and shares etc.

Best regards
Stefan



- --

S T E F A N   J U R I S C H
- --------------------------------
System Engineer - VMware Support
    - Software Development -

SIEGNETZ.IT GmbH
Schneppenkauten 1a
D-57076 Siegen

Tel. +49 271 68193- 0
Fax: +49 271 68193-28

http://www.siegnetz.de

Amtsgericht Siegen HRB4838
Gesch?ftsf?hrer: Oliver Seitz
Sitz der Gesellschaft ist Siegen

- --------------------------------

Das Wort "WINDOWS" stammt aus
einem alten Sioux-Dialekt und
bedeutet:
"Wei?er Mann starrt durch
Glasscheibe auf Sanduhr."

The word "WINDOWS" originates
from an old Sioux dialect and
means:
"White man staring through glass
pane at hourglass."

- --------------------------------


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAksCUx8ACgkQqdb99cbyCz579ACgmnK9c+RSjwcoqFEkF1LHD2V8
nnMAniRKYdE4BszRqUsNODKkuZ9FEf7j
=WCw+
-----END PGP SIGNATURE-----

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [BackupPC-users] 20000 millisecond timeout

[Jeffrey J. Kosowsky <backuppc@ko...>]

Les Mikesell wrote at about 11:09:19 -0600 on Friday, November 13, 2009:
 > Chris Baker wrote:
 > > I have already had numerous problems getting rsync to work. Rsync is not
 > > going to take care of it. It is a Windows box, and I am going to use smb.
 > 
 > Rsync is working for others on windows - but it depends on installing the 
 > correct version.

Agreed - rsync is easier, faster and more robust than smb.

Re: [BackupPC-users] Transferring backups to another backuppc installation

[Jeffrey J. Kosowsky <backuppc@ko...>]

Les Mikesell wrote at about 08:41:24 -0600 on Friday, November 13, 2009:
 > Peter Peltonen wrote:
 > > 
 > >> Note that copying a whole pool (while preserving hardlinks) is still
 > >> tough and will only work up to a certain pool size/file count (apart
 > >> from copying a whole file system image).
 > > 
 > > Do you have any more info on this (about the limits)?
 > > 
 > > Why is it so, can't rsync handle big amounts of data including hardlinks?
 > > 
 > 
 > It is not just rsync - any file oriented technique will have the same problem. 
 > The only way to match up the linked files is to build a table of filenames and 
 > inode numbers as they are copied and look up the matching inode to find the 
 > right name for the link.  The process doesn't scale well.

It may not be pretty because we don't have good tools for that
process. But it scales as n log n which is not too bad (where n log n
is the cost of sorting the table).

And if my suggestion were followed of (optionally) appending the pool
filename to the tail of each pool file then it would be O(n) and would
be faster than even rsync without hard links.