Re: [BackupPC-users] Backing up the server computer

2017-07-14 Thread Paul Fox
B wrote:
 > On Fri, 14 Jul 2017 18:56:19 -0400
 > Paul Fox  wrote:
 > 
 > > i confess i haven't been following this thread in all its gory detail,
 > 
 > The BackupPC god absolves you (although, it is the BPC v.3x god, so
 > you'll need to upgrade the confessionnal if you want to also be absolved
 > by the v.4.x one.)

:-)

 > > but i suspect that many folks do their backups onto a separately
 > > mounted disk.  if you do that, then adding "--one-file-system" to the
 > > rsync args takes care of it:  you can back up from '/', but only the
 > > root filesystem will be backed up.  any other filesystems on that
 > > machine will also need to be backed up as separate shares, of course.
 > 
 > But this way, you still backup unwanted directories, such as /tmp, /dev,
 > /proc, etc.
 > Starting on the disk root and excluding these allows for a tight control
 > over what you want and the rest, providing you need almost the whole
 > system to be saved for whatever reason.

i didn't say i don't also have some excludes.  i exclude /proc and
/sys.  /dev is a separate filesystem.  /tmp, believe it or not, i do
back up, to help with the morning-after regret of having lost a file i
thought i didn't need.  i think we're ending up in the same place -- i
just need to specifically include mounted filesystems (as separate
share), which is how i prefer it.

paul
=--
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 58.1 degrees)


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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/


Re: [BackupPC-users] Backing up the server computer

2017-07-14 Thread Bzzzz
On Fri, 14 Jul 2017 18:56:19 -0400
Paul Fox  wrote:

> i confess i haven't been following this thread in all its gory detail,

The BackupPC god absolves you (although, it is the BPC v.3x god, so
you'll need to upgrade the confessionnal if you want to also be absolved
by the v.4.x one.)

> but i suspect that many folks do their backups onto a separately
> mounted disk.  if you do that, then adding "--one-file-system" to the
> rsync args takes care of it:  you can back up from '/', but only the
> root filesystem will be backed up.  any other filesystems on that
> machine will also need to be backed up as separate shares, of course.

But this way, you still backup unwanted directories, such as /tmp, /dev,
/proc, etc.
Starting on the disk root and excluding these allows for a tight control
over what you want and the rest, providing you need almost the whole
system to be saved for whatever reason.

Jean-Yves

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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/


Re: [BackupPC-users] Backing up the server computer

2017-07-14 Thread Paul Fox
B wrote:
 > On Fri, 14 Jul 2017 18:22:54 -0400
 > Bob Katz  wrote:
 > 
 > > Oh boy  I get it!!! I can't believe how stupid I was about that. 
 > 
 > Me too ;-p)
 > 
 > > Well, doesn't this mean I have to establish a whole bunch of modules 
 > > with a different path for each module, in order to back up everything 
 > > EXCEPT the backup location? Maybe I should try a different method than 
 > > rsyncd
 > 
 > You can still use '/', but that means you'll have to exclude all
 > unwanted directories - I use BPC this way 'cos I really need the
 > whole system being backed up.

i confess i haven't been following this thread in all its gory detail,
but i suspect that many folks do their backups onto a separately
mounted disk.  if you do that, then adding "--one-file-system" to the
rsync args takes care of it:  you can back up from '/', but only the
root filesystem will be backed up.  any other filesystems on that
machine will also need to be backed up as separate shares, of course.

paul
=--
paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 59.2 degrees)


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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/


Re: [BackupPC-users] Backing up the server computer

2017-07-14 Thread Bzzzz
On Fri, 14 Jul 2017 18:22:54 -0400
Bob Katz  wrote:

> Oh boy  I get it!!! I can't believe how stupid I was about that. 

Me too ;-p)

> Well, doesn't this mean I have to establish a whole bunch of modules 
> with a different path for each module, in order to back up everything 
> EXCEPT the backup location? Maybe I should try a different method than 
> rsyncd

You can still use '/', but that means you'll have to exclude all
unwanted directories - I use BPC this way 'cos I really need the
whole system being backed up.

Jean-Yves

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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/


Re: [BackupPC-users] Backing up the server computer

2017-07-14 Thread Bob Katz
Dear Stefan, you are so kind! This helps a lot. Yes, I'm plodding my way 
through. You wrote:






[Backup-Data-Folder]
## Next, set the path you want backed up. Be sure to use a trailing
slash
path= /

Please don't do that:
o a Linux system has virtual file systems mounted (/proc, /temp,
   /sys/ ...) that will either not be readable, change during
   access or may lead to endless loops.





o this includes your /var/lib/backuppc directory. That's where
   your backup goes, so you backup your backup. It won't take long
   until the backup of backups of backups (...) will fill up your drive.
   I'd go for /etc at this point and add additional paths later, when
   this works.


Oh boy  I get it!!! I can't believe how stupid I was about that. 
Well, doesn't this mean I have to establish a whole bunch of modules 
with a different path for each module, in order to back up everything 
EXCEPT the backup location? Maybe I should try a different method than 
rsyncd




Most probably, BackupPC will try to connect as user backuppc, not root.
At least, that's the default.


I have root as the user for backuppc for all my other hosts and it 
works. And it's also currently set up as root for backing up the server. 
I did try "backuppc" as the user before and it failed, maybe for 
different reasons. Anyway, I'm not sure how confused the app backuppc 
would be in the case of trying to back up itself. The server app 
backuppc is running as the user "backuppc", but I do know that it can 
call through port 873 as the user "root" when it is backing up all the 
other clients. Yeah, I'm confused  :-)


From your description of how the secrets file works, it would seem to 
me that I've got that covered right now with my secrets file having one 
line describing a user called "root" with its password and in the 
config, auth users is root. Not the most elegant but I don't see a 
conflict there.



Best wishes,


Bob

--

If you want good sound on your album, come to Bob Katz 407-831-0233 
DIGITAL DOMAIN MASTERING STUDIO Author: *Mastering Audio *Digital Domain 
Website  No trees were killed in the sending of 
this message. However a large number of electrons were terribly 
inconvenienced.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
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/


Re: [BackupPC-users] Backing up the server computer

2017-07-14 Thread Stefan Peter
Hi Bob

On 14.07.2017 21:32, Bob Katz wrote:

... snip ...
> 
> 
> 2017/07/14 15:06:17 [3292] connect from localhost (::1)
> 2017/07/14 15:06:17 [3292] rsync denied on module Backup-Data-Folder
> from localhost (::1)
> 

... snip ...

> 
> ###
> ##
> ##  RSYNCD config file for the backuppc server
> ##
> ###
> 
> 
> transfer logging = false
>  lock file = /var/run/rsync.lock
>  log file = /var/log/rsyncd.log
>  pid file = /var/run/rsyncd.pid
>  port=873
>  address=localhost.localdomain
>  uid=root
>  gid=root
>  use chroot=yes
>  read only = no
> ## host allow: this is important.
> ## In my case leaving the subnet-mask leads to a failure,
> ## so I only provide the IP.
>hosts allow = 192.168.0.217, localhost.localdomain

I'd use
hosts allow = 192.168.0.217, 127.0.0.1

because something has to translate localhost.localdomain to an IP
address and if this fails for whatever glitch of the day is present in
name resolution, your backup will fail, too.


>  motd file=/etc/rsyncd/rsyncd.motd
>  
> ## Now you have to declare, in brackets, the RSYNC 'module', or "share
> name" as it is called within backuppc
>[Backup-Data-Folder]
>## Next, set the path you want backed up. Be sure to use a trailing
> slash
>path= /

Please don't do that:
o a Linux system has virtual file systems mounted (/proc, /temp,
  /sys/ ...) that will either not be readable, change during
  access or may lead to endless loops.

o this includes your /var/lib/backuppc directory. That's where
  your backup goes, so you backup your backup. It won't take long
  until the backup of backups of backups (...) will fill up your drive.
  I'd go for /etc at this point and add additional paths later, when
  this works.

>read only   = no
>list= yes
>auth users = root

Most probably, BackupPC will try to connect as user backuppc, not root.
At least, that's the default.

See 'man rsyncd.conf' (and search for 'auth users'). Please note that
auth users is just a user name (which needs a corresponding password in
the secrets file). This does not translate to actual users on the
system, the user name (and the the corresponding password from the
secrets file) are just used to govern access to the rsyncd server share.
the access rights to the files are deined by the user rsyncd runs under,
so in your case

>  uid=root
>  gid=root



And have a look at the 'secrets file' section right below.


BTW, it is cool that you are still on it and, despite all the troubles
you went through, did not abandon the whole project!

With kind regards

Stefan Peter

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
(See https://en.wikipedia.org/wiki/Posting_style for details)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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/


Re: [BackupPC-users] Backing up the server computer

2017-07-14 Thread Bob Katz
Still not much progress but I've simplified things. In Fedora, rsync
daemon is supposed to be run by systemctl. But I am pretty sure my
attempt to create a service for rsync as a daemon has failed somewhere.
So I'm debuggin by using the simple command line: sudo rsync ---daemon 

By the way, rsync does not accept the --foreground command as a daemon

Furthermore, the ps x | grep rsync   does NOT show me the fact that the
daemon is running, but I have every clue that it is, or at least seems
to be as hope you will agree. I can inspect the rsync daemon log,
showing a sequence of testing that I performed:

a)

2017/07/14 15:04:52 [3129] rsync: failed to create pid file
/var/run/rsyncd.pid: File exists (17)

 that was me trying to run the daemon a second time as part of a
test. Anyway, at that point I killed the process shown in the pid file
and then I deleted the pid file.




b) Then I tested rsync localhost.localdomain:: to prove that the daemon
is NOT running:


2017/07/14 15:04:52 [3129] rsync error: error in file IO (code 11) at
clientserver.c(1113) [Receiver=3.1.2]


c) Then I launched the daemon again:


2017/07/14 15:05:43 [3233] rsyncd version 3.1.2 starting, listening on
port 873


d) Then I ran rsync localhost.localdomain::  which displayed the module
 name in the terminal and this log entry resulted:

2017/07/14 15:05:54 [3241] connect from localhost (::1)
2017/07/14 15:05:54 [3241] module-list request from localhost (::1)


e) Lastly, I commanded backuppc to run a full backup of this "client"
(it's actually the server itself). Backuppc went into idle with an
immediate backup failure. The rsync daemon log shows:


2017/07/14 15:06:17 [3292] connect from localhost (::1)
2017/07/14 15:06:17 [3292] rsync denied on module Backup-Data-Folder
from localhost (::1)


So I have to find out why the rsync daemon is denying access to
backuppc. Is it the backuppc configuration? Backuppc is configured as
rsyncd, connected as root with the root password. Just in case, I put
root and root password into the secrets file. This is a lot of
overkill! 

Here is my rsyncd.conf file. I allow the host's ip and the domain name
just in case. There are a few remant lines from other attempts that I
hope are not hurting the config. I think The motd line  is a remnant of
my attempts to run rsync daemon using a service. I hope it is not
interfering with this simpler approach launching the daemon from the
command line:


###
##
##  RSYNCD config file for the backuppc server
##
###


transfer logging = false
 lock file = /var/run/rsync.lock
 log file = /var/log/rsyncd.log
 pid file = /var/run/rsyncd.pid
 port=873
 address=localhost.localdomain
 uid=root
 gid=root
 use chroot=yes
 read only = no
## host allow: this is important.
## In my case leaving the subnet-mask leads to a failure,
## so I only provide the IP.
   hosts allow = 192.168.0.217, localhost.localdomain
 motd file=/etc/rsyncd/rsyncd.motd
 
## Now you have to declare, in brackets, the RSYNC 'module', or "share
name" as it is called within backuppc
   [Backup-Data-Folder]
   ## Next, set the path you want backed up. Be sure to use a trailing
slash
   path= /
   read only   = no
   list= yes
   auth users = root
   hosts allow = 192.168.0.217, localhost.localdomain
   secrets file = /etc/rsyncd.secrets
   ## the easiest way is to use the root user
   ## This user has "ROOT"-privileges, so he can save files.
   uid = root
   gid = nogroup


   # uid = backuppc
   # gid = backuppc




##


Bob Katz, hope someone can catch my error. Very sorry for the
bandwidth. 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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/


Re: [BackupPC-users] Backing up the server computer

2017-07-14 Thread Bob Katz
Thanks. Well, first I have to ensure that inetd and no other mechanism I 
foolishly initiated in my efforts is running. I'm working on that now.


But is there a point to running sudo rsync  if the object is to use 
systemctl to run the daemon? Is that for a test or permanent? Yes, I'm 
confused :-)  And systemctl has already been initiated.



Bob


On 7/14/17 6:02 AM, Kenneth Porter wrote:
--On Thursday, July 13, 2017 4:37 PM + Michael Stowe 
 wrote:



At this point, I'd recommend

sudo rsync --daemon --foreground --verbose

So you can actually tell what's happening.


According to the man page, --foreground should be --no-detach. That 
keeps the daemon from disappearing and causes its output to appear on 
the terminal. So the command would be:


sudo rsync --daemon --no-detach --verbose

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


-- 


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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/


--

If you want good sound on your album, come to Bob Katz 407-831-0233 
DIGITAL DOMAIN MASTERING STUDIO Author: *Mastering Audio *Digital Domain 
Website  No trees were killed in the sending of 
this message. However a large number of electrons were terribly 
inconvenienced.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
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] Ran out of inodes

2017-07-14 Thread Tapio Lehtonen
Running BackupPC 3 on Debian Wheezy. Ran out of inodes on 250 GB
filesystem, max inodes was 15 million. Can the nightly cleanup now run
and maybe release some idodes from the oldest backups?

Since the filesystem is Ext4 I can not increase max inodes. Would it
reduce the need of inodes if I reduced the number of backups to keep?

My quess is users have lots of e-mails stored and since those tend to be
small they eat up the inodes.

-- 
Tapio Lehtonen
OSK Satatuuli http://satatuuli.fi/
<>--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
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/


Re: [BackupPC-users] Backing up the server computer

2017-07-14 Thread Kenneth Porter
--On Thursday, July 13, 2017 12:03 PM -0400 Bob Katz  
wrote:



There must be a foolproof way of displaying running daemons, finding out
the PID and killing it.  The PS command that everyone is fond of does not
show the daemon is runnning, I don't believe.


If ps doesn't see it, then it's not there. There's no magically more 
powerful command for peeking inside the kernel at running processes.


So likely rsync starts and then immediately exits with some problem in the 
configuration.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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/


Re: [BackupPC-users] Backing up the server computer

2017-07-14 Thread Kenneth Porter
--On Thursday, July 13, 2017 4:37 PM + Michael Stowe 
 wrote:



At this point, I'd recommend

sudo rsync --daemon --foreground --verbose

So you can actually tell what's happening.


According to the man page, --foreground should be --no-detach. That keeps 
the daemon from disappearing and causes its output to appear on the 
terminal. So the command would be:


sudo rsync --daemon --no-detach --verbose

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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/