I have a similar situation as the original poster -- my initial full
backup is too large to do over my internet connection. I solved the
problem last night by physically moving the host machine to the local
network of the backup server (though it could have been another machine
with a copy of the data to be backed up). I left all my BackupPC config
files as they were, and I edited /etc/hosts on the BackupPC server so
that the internet URL of the host machine points to its IP address on
the local network. For instance:
192.168.1.100 myurl.dyndns.org
Basically, I tricked my machine into looking for the host on the local
network instead of on the internet. It worked, and I didn't have to
edit my BackupPC configs at all.
-Rob
Holger Parplies wrote:
> Hi,
>
> Keith Edmunds wrote on 06.08.2007 at 13:48:26 [Re: [BackupPC-users] Priming
> an initial backup]:
>
>> On Mon, 06 Aug 2007 07:45:03 -0500, [EMAIL PROTECTED] said:
>>
>>
>>> You should be able to get the same effect by backing it up from some
>>> other machine on the local lan with the server - perhaps a laptop or
>>> other temporary addition, then changing the pc directory name and the
>>> name in the hosts entry to the real one.
>>>
>> Or use $Conf{ClientNameAlias} to temporarily point at the temporary
>> machine.
>>
>
> I believe both the client name and the directory are coded into the path
> names in the pc/ directory, so if you want to keep it simple, you want to
> use the same client name and backup directory as you will later on. As Keith
> pointed out, the most simple approach for the client name is to use
> ClientNameAlias to "temporarily" (i.e. for the first backup) point the
> backup to a different host. For the directory name, things remain simple if
> you're going to use rsyncd as transfer method, as you'd just define the
> rsyncd module with the same name and arbitrary path on the client machines
> (which would not need to be identical for the temporary host and the real
> one).
>
> Actually, you want to be using either rsync or rsyncd as transfer method,
> because you can't get by without occasional full backups. With the rsync
> type transfer methods, these should not transfer much more data across the
> network link than incrementals - believe it or not, in some cases even
> less :).
>
> For a previous answer to much the same question, see
> http://sourceforge.net/mailarchive/message.php?msg_name=20070615011832.GL25826%40mail.parplies.de
> or
> http://sourceforge.net/mailarchive/message.php?msg_name=20070510205559.78bf3fff%40ws.rg2.tiger-computing.com
> (Keith wrote that he did some things differently and offered to summarize :).
>
> More on why you need full backups:
> http://sourceforge.net/mailarchive/message.php?msg_name=20070501024958.GM25826%40mail.parplies.de
>
> Regards,
> Holger
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> BackupPC-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/backuppc-users
> http://backuppc.sourceforge.net/
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
BackupPC-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
