[BackupPC-users] Backups fails with different errors
Hi list I have problems with backup one host. Everythign works well, but since half of january i get strange errors, and no successfull backups. Strange thing is that sometimes backup fails after a while and sometimes after log time e.g. 400 minutes, and somtimes with one error and next time with different error. I have tried upgrade File-Rsync and rsync on the client machine, but without success. And also i have upgraded to backuppc3.0, but with same issue. I really don't know where the problem can be. Can you plese take a look at my logs and possibly tell me where the problem can be, or how shuld i debug this problem ? Last logs are here http://komodo.webz.cz/get/LOG.z http://komodo.webz.cz/get/XferLOG.411.z http://komodo.webz.cz/get/XferLOG.bad http://komodo.webz.cz/get/XferLOG.bad.z.old Thank you for your help -- komodo http://komodo.webz.cz - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] Backing up large directories times out with signal=ALRM or PIPE
Les Mikesell wrote:
Apologies for the relatively long email, but I figure it's better to
give too much information than not enough. I've run into a bit of
difficulty backing up a large directory tree that has me not being
able to do a successful backup in over a month now. I'm attempting to
back up about 70GB over the Internet with a 1 MB/sec connection (the
time it takes doesn't really bother me, just want to do a full backup
and then run incrementals all the time). However, the transfer
always
times out with signal=ALRM.
ALRM should mean the server's $Conf{ClientTimeout} expired. You may
need to make it much longer. The time is supposed to mean
inactivity but
some circumstances make it the total time for a transfer to complete.
signal=PIPE means the connection broke or the client side quit
unexpectedly.
Although the ALRM and PIPE signals are probably technically correct
it might be clearer to use different terms/explanations in the
interface. I have the feeling not everyone understands these signals.
Nils Breunese.
PGP.sig
Description: Dit deel van het bericht is digitaal ondertekend
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
Re: [BackupPC-users] Backing up large directories times out with signal=ALRM or PIPE
Nils Breunese (Lemonbit) wrote:
Apologies for the relatively long email, but I figure it's better to
give too much information than not enough. I've run into a bit of
difficulty backing up a large directory tree that has me not being
able to do a successful backup in over a month now. I'm attempting to
back up about 70GB over the Internet with a 1 MB/sec connection (the
time it takes doesn't really bother me, just want to do a full backup
and then run incrementals all the time). However, the transfer always
times out with signal=ALRM.
ALRM should mean the server's $Conf{ClientTimeout} expired. You may
need to make it much longer. The time is supposed to mean inactivity but
some circumstances make it the total time for a transfer to complete.
signal=PIPE means the connection broke or the client side quit
unexpectedly.
Although the ALRM and PIPE signals are probably technically correct it
might be clearer to use different terms/explanations in the interface. I
have the feeling not everyone understands these signals.
man signal
will show all the possibilities. SIGPIPE isn't very clear because it
really just means a child process terminated while the parent is still
trying to communicate with it, but in this case the child is the ssh,
rsync, or smbclient that is doing the transfer from the remote and the
likely reasons are either a network problem or that the remote side
terminated.
--
Les Mikesell
[EMAIL PROTECTED]
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
[BackupPC-users] web interface problems in 3.0.0
Hi. I posted this in other thread but I got no answer, so if someone could help me I'll appreciate it. I've upgraded from 2.1.1 to 3.0.0 in a debian sarge, and some problems arise.. First it was the error about the language, and resolved it by renaming /etc/backuppc and reinstalling the 3.0.0 version. Then some errors appeared when backing up hosts, and the web interface edit configuration does not work, either manual incr/full backup button! When I press them I get back to home page. I thought it has something to do with mod_perl, it didnt appeared with apache -l command. so I installed it with apt-get install libapache-mod-perl, but it still didnt show mod_perl so I gave up on that. also I putted in httpd.conf the config like in the docs- http://kent.dl.sourceforge.net/sourceforge/backuppc/BackupPC-3.0.0.html#step_9__cgi_interface now what is really strange is that I have a lot of folders with special characters with accents and other portuguese language symbols, but I managed to put it working correcly in the last version, but now only the folders tar appear right, in the files some are missing, those are filenames with special characters. here is what I'm talking about: http://img57.imageshack.us/my.php?image=backuppcnamesyb0.png the host is an NT4 server... - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] Backing up large directories times out with signal=ALRM or PIPE
Les Mikesell wrote: Although the ALRM and PIPE signals are probably technically correct it might be clearer to use different terms/explanations in the interface. I have the feeling not everyone understands these signals. man signal will show all the possibilities. SIGPIPE isn't very clear because it really just means a child process terminated while the parent is still trying to communicate with it, but in this case the child is the ssh, rsync, or smbclient that is doing the transfer from the remote and the likely reasons are either a network problem or that the remote side terminated. I know I can take a look at the man pages, but I still think it would better for the web interface to display something a bit clearer than just the signal name. Nils Breunese. PGP.sig Description: Dit deel van het bericht is digitaal ondertekend - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] Backing up large directories times out with signal=ALRM or PIPE
Nils Breunese (Lemonbit) wrote: Les Mikesell wrote: Although the ALRM and PIPE signals are probably technically correct it might be clearer to use different terms/explanations in the interface. I have the feeling not everyone understands these signals. man signal will show all the possibilities. SIGPIPE isn't very clear because it really just means a child process terminated while the parent is still trying to communicate with it, but in this case the child is the ssh, rsync, or smbclient that is doing the transfer from the remote and the likely reasons are either a network problem or that the remote side terminated. I know I can take a look at the man pages, but I still think it would better for the web interface to display something a bit clearer than just the signal name. I haven't looked at the code, but it probably just picks up the error or exit status and its description as returned by the operating system. Things like 'no space on device' or 'permission denied' are a little more understandable but there are a lot of possibilities for failure. -- Les Mikesell [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
[BackupPC-users] FullKeepCnt confusion
I'm running 2.1.2pl1 on debian sarge and have one big BackupPC server
backing up three big fileservers. I noticed today that the BackupPC
filesystem is 91% full:
Pool file system was recently at 91% (2/20 23:00), today's max is 91%
(2/20 08:54) and yesterday's max was 91%.
And I see that I have 3 full backups of all three servers (all
1.5-2TB). Figuring that it must be configured to keep 3 fulls, I
went in to lower the number and find that it's set to 1:
$Conf{FullKeepCnt} = 1;
So, my guess is that BackupPC keeps as many fulls as it thinks it can
get away with, but my concern is what happens if the the servers
continue to accumulate more data? Am I going to run out of space, or
will it keep less fulls? And I'm assuming less fulls will only help
if the data is changing a lot. I believe it is changing a lot on at
least one of the servers. The biggest server is relatively static.
Thanks in advance,
James
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
Re: [BackupPC-users] FullKeepCnt confusion
James Ward wrote:
I'm running 2.1.2pl1 on debian sarge and have one big BackupPC server
backing up three big fileservers. I noticed today that the BackupPC
filesystem is 91% full:
Pool file system was recently at 91% (2/20 23:00), today's max is 91%
(2/20 08:54) and yesterday's max was 91%.
And I see that I have 3 full backups of all three servers (all
1.5-2TB). Figuring that it must be configured to keep 3 fulls, I
went in to lower the number and find that it's set to 1:
$Conf{FullKeepCnt} = 1;
So, my guess is that BackupPC keeps as many fulls as it thinks it can
get away with, but my concern is what happens if the the servers
continue to accumulate more data? Am I going to run out of space, or
will it keep less fulls? And I'm assuming less fulls will only help
if the data is changing a lot. I believe it is changing a lot on at
least one of the servers. The biggest server is relatively static.
It will also keep any fulls needed to support the number of incrementals
you keep.Normally you end up with one more full than your
FullKeepCnt because of this but it will depend on your incremental
counts. Running fulls more often in the schedule would reduce the need
to keep them as the backing for subsequent incrementals.
Data that does not change between runs should not take additional
storage, but even a slight change will make a new complete copy. If you
have large growing log files you might rotate them more often. If you
have large mailbox files in standard unix format you might convert to
maildir format. This kind of change helps backuppc retain the unchanged
files instead of duplicating the content in growing files.
--
Les Mikesell
[EMAIL PROTECTED]
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
Re: [BackupPC-users] web interface problems in 3.0.0
On 2/21/07, Filipe [EMAIL PROTECTED] wrote: I've upgraded from 2.1.1 to 3.0.0 in a debian sarge, and some problems arise.. First it was the error about the language, and resolved it by renaming /etc/backuppc and reinstalling the 3.0.0 version. I saw the same problem in the same situation. In the Debian package, it looks for the configs in /etc/backuppc, but the 2.0.0 tarball looks to /etc/BackupPC. I symlinked them together. Then some errors appeared when backing up hosts, and the web interface edit configuration does not work, That is a permissions issue, and it is tied into the next problem as well. The user backuppc needs to be able to write in the /etc/BackupPC directory, and create subdirectories. In debian, the /etc/backuppc was installed as root:root, and to edit I switched the ownership to backuppc:www-data. Once backuppc is the owner of /etc/BackupPC, it will be able to write to the config files, and create/modify the individual pc configs in the subdirectory /etc/BackupPC/pc, which will be created the first time you modify a host's config. either manual incr/full backup button! When I press them I get back to home page. I saw the exact same thing. The problem was that the sticky bit on the BackupPC_Admin script in the cgi-bin had been altered. This page on the FAQ helped me sole it - http://backuppc.sourceforge.net/faq/debugCGI.html , specifically the section with the script. For Debian, perl usually isn't in /bin/perl, but rather /usr/bin/perl. The BackupPC_Admin file needs to have these permissions on Debian, or it generally won't work, and cause exactly the problems you were seeing: -r-sr-x--- 1 backuppc www-data 3993 2007-02-12 15:57 BackupPC_Admin The sticky must be set on execute as owner, backuppc or the failures will occur. Setting those permissions is covered both in the man page and on the FAQ I cited above. I thought it has something to do with mod_perl, it didnt appeared with apache -l command. so I installed it with apt-get install libapache-mod-perl, but it still didnt show mod_perl so I gave up on that. also I putted in httpd.conf the config like in the docs- http://kent.dl.sourceforge.net/sourceforge/backuppc/BackupPC-3.0.0.html#step_9__cgi_interface now what is really strange is that I have a lot of folders with special characters with accents and other portuguese language symbols, but I managed to put it working correcly in the last version, but now only the folders tar appear right, in the files some are missing, those are filenames with special characters. here is what I'm talking about: http://img57.imageshack.us/my.php?image=backuppcnamesyb0.png the host is an NT4 server... Sorry, this part I can't help you with. I was seeing language errors until I switched the ownership of /etc/BackupPC to backuppc, then they disappeared. Maybe you'll have the same result. Peace, Jim - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] Update to 3.0
On 2/20/07, Carl Wilhelm Soderstrom [EMAIL PROTECTED] wrote: On 02/20 12:39 , Nils Breunese (Lemonbit) wrote: All my clients are servers with fast connections. I'll take MaxBackups down to 1 then. I haven't done any thorough empirical testing on this, but I suspect that MaxBackups=2 would give you higher throughput overall (tho not individually). the reason is that the processor and disk are going to have idle moments (unless they're very slow, or memory is very limited), where they're waiting on data from the remote end. So if you have two jobs running, you'll be more likely to always have a job ready to use resources as they become available. really, you'll have to test with your specific environment; but that's just my experience and thinking. In my experience I've found that setting MaxBackups to 1-2 normally results in the best behavior. When backing up clients across a WAN, more than 2 often simply saturates the network. When backing up local clients, you only want one more backup running than CPUs and disks. The more CPUs, disk spindles and network bandwidth you have, the more you can bump up the number of concurrent backups. Without presenting and undue load on the backup server or network. As Carl mentions, monitoring system utilization using top sar is key to maximizing throughput. -Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] backuppc 3.0 blackout
Hi,
ADNET Ghislain wrote on 21.02.2007 at 12:20:23 [[BackupPC-users] backuppc 3.0
blackout]:
I use a blackout like this:
# pas de backup sauf entre entre 1h et 6h
$Conf{BlackoutPeriods} = [
{
hourBegin = 6.5,
hourEnd = 0.5,
weekDays = [0, 1, 2, 3, 4, 5, 6],
},
];
so it should stop backups after 6h30 and start again when it hits 0h30 am
BackupPC will not *stop backups*, it just won't start new ones during the
backup period, provided other conditions are met.
and in the /pc/hostname.pl i do :
You can't set blackout periods on a per-host basis, only globally in
config.pl.
do /etc/BackupPC/blackout-1-6.pl;
but even with that i have the backuppc service that backup my host in
the middle of the day, the date of the server is ok. I restarted it
several time but it continue to launch backup in middle of the day. Any
idea of what is wrong here ?
Check $Conf{BlackoutGoodCnt}. Blackouts only apply to hosts that have this
many consecutive good pings (as stated in the documentation). This state is
reset after $Conf{BlackoutBadPingLimit} bad pings.
To have your hosts always subjected to the blackout period, set
$Conf{BlackoutGoodCnt} to 0. Another tip from the excellent documentation
right in the config file is to set the $Conf{WakeupSchedule} accordingly if
you don't want any backups during a specific time window.
Use the force, read the docs.
Regards,
Holger
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
Re: [BackupPC-users] Backing up large directories times out with signal=ALRM or PIPE
Hi,
Jason B wrote on 20.02.2007 at 20:28:59 [Re[2]: [BackupPC-users] Backing up
large directories times out with signal=ALRM or PIPE]:
[...] $Conf{ClientTimeout} will need to be at least 72000 [...]
I see. I must've been misunderstanding the meaning of that setting -
my original impression was that it be the time that it would wait, at
most, if nothing is happening before it times out - I assumed that if
files are being transferred, that is sufficient activity for it to
keep re-setting that timer. [...]
that is the way it would ideally be supposed to work. Unfortunately that's
not really easy to implement, as the instance (i.e. process) *watching* the
transfer is not the one *doing* the transfer. Apparently, the tar and smb
transfer methods are a bit better than rsync(d) in that the alarm time is
reset whenever (informational) output from the tar command is received. This
is not really an advantage, because you're dependent on the transfer time of
the largest file instead of the total backup. File sizes probably vary more
than total backup sizes.
You don't really want to do that, for various reasons.
Would you suggest, in that case, to lower the frequency of
incrementals, and raise the frequency of full backups? I was going on
the idea of doing an incremental once every 2 days or so, and a full
backup once a month (because of the size of the data and the
persistent timeouts).
Well, you *wrote* you wanted no full backups at all. Whether one month is a
good interval for full backups or not really depends on your data, the
changes, your bandwidth, and your requirements. If you require an exact
backup that is at most a week old (meaning no missed changes are acceptable),
then you'll need a weekly full. If the same files change every day, your
incrementals won't grow as much as if different files change every day. If
the time a backup takes is unimportant, as long as it finishes within 24
hours, you can probably get away with longer intervals between full backups.
If bandwidth is more expensive than server load, you'll need shorter
intervals. You'll have to work out for yourself, which interval best fits
your needs. I was just saying: no fulls and only incrementals won't work.
You can always configure monthly (automatic) full backups and then start one
by hand after a week. See how long that takes. Start the next one after
further two weeks. See how much interval you can get away with. Or watch how
long your incrementals are taking. BackupPC provides you with a lot of
flexibility.
Concerning the incremental backups: if you need (or want) a backup every two
days, then you should do one every two days. If that turns out to be too
expensive in terms of network bandwidth, you'll have to change something.
Doing *each backup as a full backup* (using rsync(d)!) will probably minimize
network utilisation at the expense of (much!) server load. Again: there's no
one fits all answer.
Jason Hughes explained how to incrementally transfer such a structure using
$Conf{BackupFilesExclude}. The important thing is that you need successful
backups to avoid re-transferring data, even if these backups at first
comprise only part of your target data. [...]
What I currently have is a rsyncd share for about 10 - 12 different
subdirectories (I drilled down a level with the expectation that
splitting into separate shares might help with the timeouts; I have
not considered the possibility of backing up separately, though).
By that token, I would imagine that I just comment out the shares I
don't need at present, and re-activate them once the backups are done,
right? And once I've gone through the entire tree, just enable them
all and hope for the best?
I'm not sure I understand you correctly.
The important thing seems to be: define your share as you ultimately want it
to be. Exclude parts of it at first (with $Conf{BackupFilesExclude}) to get
a successful backup. Altering $Conf{BackupFilesExclude} will not change your
backup definition, i.e. it will appear as if the share started off with a few
files and quickly grew from backup to backup. You can start a full backup by
hand every hour (after changing $Conf{BackupFilesExclude}) to get your share
populated, no need to wait for your monthly full :). Each successful full
backup (with less excluded files) will bring you nearer to your goal.
Each future full backup will be similar to the last of these steps: most of
the files are already on the backup server, only a few percent need to be
transfered.
If, in contrast, you start up with several distinct shares, you'll either
have to keep it that way forever, or re-transfer files, or do some other
magic to move them around the backups and hope everything goes well. It's
certainly possible, but it's not easy. Using $Conf{BackupFilesExclude} is,
and you can't do much wrong, as long as you finally end up excluding nothing
you don't want to exclude.
Regards,
Holger
Re: [BackupPC-users] web interface problems in 3.0.0
Jim McNamara wrote: On 2/21/07, *Filipe* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I've upgraded from 2.1.1 to 3.0.0 in a debian sarge, and some problems arise.. First it was the error about the language, and resolved it by renaming /etc/backuppc and reinstalling the 3.0.0 version. I saw the same problem in the same situation. In the Debian package, it looks for the configs in /etc/backuppc, but the 2.0.0 tarball looks to /etc/BackupPC. I symlinked them together. Then some errors appeared when backing up hosts, and the web interface edit configuration does not work, That is a permissions issue, and it is tied into the next problem as well. The user backuppc needs to be able to write in the /etc/BackupPC directory, and create subdirectories. In debian, the /etc/backuppc was installed as root:root, and to edit I switched the ownership to backuppc:www-data. Once backuppc is the owner of /etc/BackupPC, it will be able to write to the config files, and create/modify the individual pc configs in the subdirectory /etc/BackupPC/pc, which will be created the first time you modify a host's config. yeah it was sort of that... but I have also to put chmod 770 to everything in /etc/BackupPC The colours in webinterface changed, and names of files in recent backups are shown correctly. old ones are still with the same problem.. http://img341.imageshack.us/my.php?image=backp3tl4.png either manual incr/full backup button! When I press them I get back to home page. I saw the exact same thing. The problem was that the sticky bit on the BackupPC_Admin script in the cgi-bin had been altered. This page on the FAQ helped me sole it - http://backuppc.sourceforge.net/faq/debugCGI.html , specifically the section with the script. For Debian, perl usually isn't in /bin/perl, but rather /usr/bin/perl. The BackupPC_Admin file needs to have these permissions on Debian, or it generally won't work, and cause exactly the problems you were seeing: -r-sr-x--- 1 backuppc www-data 3993 2007-02-12 15:57 BackupPC_Admin The sticky must be set on execute as owner, backuppc or the failures will occur. Setting those permissions is covered both in the man page and on the FAQ I cited above. done that but it still remains the same... -rwsr-x--x 1 backuppc www-data 3993 2007-02-14 20:00 BackupPC_Admin when I go to the url http://backuppcserver/backuppc/BackupPC_Admin I got the download window from that file... it seems that I can read it ... Thanks a lot for the answers. regards. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] backuppc 3.0 blackout
On 02/22 12:41 , Holger Parplies wrote: You can't set blackout periods on a per-host basis, only globally in config.pl. actually, you can set blackouts on a per-host basis. works for me. -- Carl Soderstrom Systems Administrator Real-Time Enterprises www.real-time.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] backuppc 3.0 blackout
Hi, Carl Wilhelm Soderstrom wrote on 21.02.2007 at 20:08:03 [Re: [BackupPC-users] backuppc 3.0 blackout]: On 02/22 12:41 , Holger Parplies wrote: You can't set blackout periods on a per-host basis, only globally in config.pl. actually, you can set blackouts on a per-host basis. works for me. yes, sorry. I was thinking of the WakeupSchedule. Should have checked. Regards, Holger - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] web interface problems in 3.0.0
Another thing I had forgotten to mention was that I ended up with two BackupPC_Admin scripts, one from the .deb package, and another from the 3.0.0 tarball. The permissions you have one the one below seem a little strange to me, because everyone can execute it, and be stickied as backuppc. That may be something you elected to do, but if it wasn't, then maybe you're working with the wrong script? And you're entirely correct about the ownership of the /etc/BackupPC files. Mine looks like this: mailbox:/home/jim# ls -al /etc/BackupPC/ total 108 drwxr-x--- 3 backuppc www-data 4096 2007-02-20 11:23 . drwxr-xr-x 67 root root 4096 2007-02-19 12:00 .. -rw-r- 1 backuppc www-data 556 2007-02-14 19:02 apache.conf -rw-r- 1 backuppc www-data 77434 2007-02-17 17:11 config.pl -rw-r- 1 backuppc www-data 2292 2007-02-13 23:21 hosts -rw-r- 1 root www-data23 2007-02-20 11:23 htpasswd -rw-r- 1 root www-data43 2007-02-20 11:19 htpasswd.normal drwxr-xr-x 2 backuppc www-data 4096 2007-02-20 10:52 pc Obviously if you can select a different location for your password file. You're very welcome for the limited help I'm able to provide! Jim On 2/21/07, Filipe [EMAIL PROTECTED] wrote: Jim McNamara wrote: On 2/21/07, Filipe [EMAIL PROTECTED] wrote: I've upgraded from 2.1.1 to 3.0.0 in a debian sarge, and some problems arise.. First it was the error about the language, and resolved it by renaming /etc/backuppc and reinstalling the 3.0.0 version. I saw the same problem in the same situation. In the Debian package, it looks for the configs in /etc/backuppc, but the 2.0.0 tarball looks to /etc/BackupPC. I symlinked them together. Then some errors appeared when backing up hosts, and the web interface edit configuration does not work, That is a permissions issue, and it is tied into the next problem as well. The user backuppc needs to be able to write in the /etc/BackupPC directory, and create subdirectories. In debian, the /etc/backuppc was installed as root:root, and to edit I switched the ownership to backuppc:www-data. Once backuppc is the owner of /etc/BackupPC, it will be able to write to the config files, and create/modify the individual pc configs in the subdirectory /etc/BackupPC/pc, which will be created the first time you modify a host's config. yeah it was sort of that... but I have also to put chmod 770 to everything in /etc/BackupPC The colours in webinterface changed, and names of files in recent backups are shown correctly. old ones are still with the same problem.. http://img341.imageshack.us/my.php?image=backp3tl4.png either manual incr/full backup button! When I press them I get back to home page. I saw the exact same thing. The problem was that the sticky bit on the BackupPC_Admin script in the cgi-bin had been altered. This page on the FAQ helped me sole it - http://backuppc.sourceforge.net/faq/debugCGI.html , specifically the section with the script. For Debian, perl usually isn't in /bin/perl, but rather /usr/bin/perl. The BackupPC_Admin file needs to have these permissions on Debian, or it generally won't work, and cause exactly the problems you were seeing: -r-sr-x--- 1 backuppc www-data 3993 2007-02-12 15:57 BackupPC_Admin The sticky must be set on execute as owner, backuppc or the failures will occur. Setting those permissions is covered both in the man page and on the FAQ I cited above. done that but it still remains the same... -rwsr-x--x 1 backuppc www-data 3993 2007-02-14 20:00 BackupPC_Admin when I go to the url http://backuppcserver/backuppc/BackupPC_Admin I got the download window from that file... it seems that I can read it ... Thanks a lot for the answers. regards. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] web interface problems in 3.0.0
Hi, sticky bits make stuff sticky, not setuid. That's the setuid bit. And, oh wonder, what makes stuff setgroupid is the setgroupid bit. Also not the sticky bit. Don't worry about what sticky means. You don't need it. You need setuid. Regards, Holger - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] web interface problems in 3.0.0
Yes, apparently I have sticky on the brain! - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
Re: [BackupPC-users] web interface problems in 3.0.0
Filipe writes: now what is really strange is that I have a lot of folders with special characters with accents and other portuguese language symbols, but I managed to put it working correcly in the last version, but now only the folders tar appear right, in the files some are missing, those are filenames with special characters. here is what I'm talking about: http://img57.imageshack.us/my.php?image=backuppcnamesyb0.png In BackupPC 3.0.0 the server filename charset encoding is utf8. Translation of filename charset encodings to/from the client charset is supported by each XferMethod. In 2.x no translation was done. So the file names might or might not render correctly. Some European charsets (with simple accents) worked ok. You have exposed an incompatibility between 3.0.0 displaying backups made in 2.x, since 3.0.0 is assuming the encoding is utf8. I believe restore under 3.0.0 of 2.x backups with non-utf8 filename encodings will work correctly, but I haven't tested that. I'll work on a patch for rending the file names correctly. Craig - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
