backup strategies
Hi! We plan to set up a backup server. While the basic backup procedure is clear -- use some archiving utility like dump, tar, or cpio and send data to the backup server via ssh or a network mount -- there are many details which are unclear for me. The two biggest problems are: 1) What parts are to be backed up? If I backup the whole system, the backup disk will get full soon. You could say it's not necessary, and that only the valueable data should be backed up (and not those parts which are easy to re-create by means of a new installation). But, say, someone breaks into the machince. How could I reliably find out the Achilles heel she used to get in if I don't have a complete system backup? Or if she has a backdoor left behind? 2) How to schedule backups? I guess services should stop for the backup period as the backup could be unreliable or inconsistent if disk/file writes were going on during backup. It sounds as if I should drop to single user mode. Or is there a less drastic approach? And if I dropped to single user mode, I would lose control over the box for that period, as the box is accessed via ssh and sshd is also stopped in single user mode -- this sounds scary... TYA. -- Csaba Henk My sense of humour is often too subtle to cope with getting smileyd. Please don't take it personal. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: backup strategies
Thanks for all the tips and answers, I will consider the mentioned
alternatives.
Yet I have one more question...
On Sun, Oct 30, 2005 at 01:22:35PM -0600, Eric Schuele wrote:
> dump(8) will create a snapshot of a live filesystem, dump the snapshot
> and then remove the snapshot, if given the correct flags ('-L').
Can even a full bakcup done safely on a live filesystem by "dump -L"?
As dump(8) says when explaining the -L flag:
To obtain a consistent dump image, dump takes a snapshot of the file
system in the .snap directory in the root of the file system being
dumped and then does a dump of the snapshot.
I don't see how the temporary snapshot can improve the
reliability/consistency/correctness of the dump. Could someone explain
this?
--
Csaba Henk
My sense of humour is often too subtle to cope with getting smileyd.
Please don't take it personal.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: backup strategies
On Mon, Oct 31, 2005 at 09:40:16AM -0600, Eric Schuele wrote: > How do snapshots work and how do they provide the consistency necessary > for a dump? [...] > > SoftUpdates are required on the filesystem. This sounds beautiful. I am amazed. I knew of softupdates, but they were always a shady corner of my understanding of BSD. So live fs dumping is based on the great hackery of softupdates. Fine, but in this case... shouldn't the man page make a mention of it? It just says that -L is ignored in case of unmounted/ro mounted fs-s, or if there is no proper .snap dir. But it doesn't say that it will be ignored if softupdates is not turned on... Going a bit off: which OS-es provide this live snapshot dumping capability? FreeBSD? FreeBSD >= 5.x ? *BSD ? Maybe something else? (AFAIK, softupdates is supported also in other members of the BSD family, yet the NetBSD dump manpage didn't have such a -L flag...) -- Csaba Henk My sense of humour is often too subtle to cope with getting smileyd. Please don't take it personal. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: backup strategies
On Mon, Oct 31, 2005 at 10:32:02AM -0600, Eric Schuele wrote: > The online manual mentions it in 16.13. Wouldn't hurt for it to be in > the man page as well. Oh, yeah, thanks. This makes things clear. I missed this somehow. > AFAIK FreeBSD 5.0+. Other *BSD as well, i believe... but someone else > would have to answer that. > > >(AFAIK, softupdates is supported also in other members of the BSD > >family, yet the NetBSD dump manpage didn't have such a -L flag...) OK, as I understand now, softupdates might be available for other BSD-s, but snapshotting is not a "free bonus" which comes with softupdates, but a new innovation based on that... and is a true FBSD innovation. So I'd guess it's still a unique thing. -- Csaba Henk My sense of humour is often too subtle to cope with getting smileyd. Please don't take it personal. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: backup strategies
On Mon, Oct 31, 2005 at 02:37:32PM -0500, Paul Mather wrote: > Not quite: NetBSD also features softupdates and also supports snapshots > (though I don't know how stable it is, as I've never tried it on my > NetBSD system). The snapshot interface under NetBSD is different from That's also good to know. Thanks for the information. -- Csaba Henk My sense of humour is often too subtle to cope with getting smileyd. Please don't take it personal. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Explaining FreeBSD features (OT: end user policies)
On Tue, Jun 21, 2005 at 01:05:32AM -0700, Ted Mittelstaedt wrote: > This gives rise to a rather serious Catch-22 with FreeBSD: > > You need to really understand intimately how FreeBSD works > and how computer software that runs on it works in order to > get it to work well enough for you to learn intimately how it > works. > > Windows and Linux solved this Catch-22 by dumbing-down the > interface to their operating systems. Thus, an ignoramus > can get up and running with both of these systems, and that > person can remain fat, dumb, and happy, completely ignorant > of what he is doing, and those systems will still work enough > to get the job done. It may be a half-assed fix, but it is > better than nothing. Concerning Linux, I feel you generalize far too uncautiously. >From the POV of this discussion, there is no such thing as Linux OS. Linux is just a kernel, as we know. There is no such a thing as Gnu/Linux OS, either. Gnu/Linux is just a set of regularly updated source tarballs. RedHat, Debian, Gentoo, SuSe, ... are operating systems. Each of them is comparable with Windowses and BSDs in respect of end user policies -- but the Linux kernel and the Gnu/Linux packages as such don't interfere with end users. Some of them are dumbed down, others are not. Concerning the dumbed down ones: I'm eager to see one which passes the following test. Toss in a data CD. The system will automount it and place an icon on the desktop. Click on the icon, you'll get a file browser showing the contents of the CD. Now look up the "eject" menupoint in the (usually right-click) menu of the CD icon, and click on it. Do you get an error message which makes sense for a computer-ignorant user? Do you get any hint how to resolve the problem? I don't dare to suggest an alternative to Windows using (and cursing) friends and relatives where one can't answer "yes" to these questions. That is, you have to distinguish within "dumbed down interfaces", too. Csaba ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Apache2 + mod_python problems
On Thu, Jun 23, 2005 at 12:18:49PM -0400, Chad Morland wrote: > I am having problems getting mod_python and apache2 ports to work properly. > > Here are the relevant ports that I have installed: > apache-2.0.54 > mod_python-3.1.4_1 > python-2.4.1_1 > > When I try and start apache I get the following: > > pxetest# apachectl start > Syntax error on line 276 of /usr/local/etc/apache2/httpd.conf: > Cannot load /usr/local/libexec/apache2/mod_python.so into server: > /usr/local/libexec/apache2/mod_python.so: Undefined symbol > "pthread_attr_init" Can it be that you have installed mod_python with thread support enabled, but your python is w/o thread support? I had mysterious errors with mod_python (the error messages had nothing to do with threads) until I disabled threads both in python and mod_python. Csaba ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fuser equivalent
On Mon, Jul 04, 2005 at 06:03:43PM +0800, Crucis wrote: > Is there a BSD equivalent of the Linux "fuser" command? > fuser is used to identify processes using files/sockets.i There is fstat in the base system. Csaba ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: using -t option with unix sort ?
On Thu, Jul 14, 2005 at 10:47:50AM -0700, Daniel Malaby wrote:
> The sample data has 9 fields, I am trying to sort on the fifth field,
> here is what I have tried.
>
> sort -t\t +4 -5 -o test.txt sample.txt
>
> I did try removing the space and it did not work, I have also tried
> removing the -5. I think the spaces in the third field are confusing sort.
Well, if you are willing to accept a non-orthodox solution,
ruby -e 'puts $<.readlines.sort_by {|x| x.split(/\t/)[4]}' sample.txt > test.txt
will do the job.
I guess there should be a succint way of doing this with perl, too.
Csaba
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
early panic and dump
I sent the following post to freebsd-current, but maybe it's better to be sent to questions -- the problem of dumping as such is not a current-specific question... > Hi! > > I tried to install both RELENG-6 and CURRENT, and both kernels behaved > the same way: panicked quite early (before init) with a page fault. Has > anyone met with this phenomena? > > I'd like to show you some fancy backtracks, but as it all happened before > starting init, rc.conf settings won't help me in getting the dump. > > What I've read: > > "the dump device can be hard-coded via the dump clause in the config(5) > line of a kernel configuration file." > > But putting > > dump /dev/ad0s4 > > into the config file is considered a syntax error, and the man page > of config doesn't contain anything about dumping. > > Another thing which I found on the net suggests setting the dumpdev > variable in the loader(8). I can do that, but it doesn't make a difference, > and again, the man page doesn't mention dumping. > > How to get that wacky dump these days? > > TIA. > > Cheers, > Csaba Note that the above quote is from Developers Handbook and the full quote is: Alternatively, the dump device can be hard-coded via the dump clause in the config(5) line of a kernel configuration file. This approach is deprecated and should be used only if a kernel is crashing before dumpon(8) can be executed. And that I fall into the "only if" case. Thanks. Csaba ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Determining what a port will install... (more than pretty-print-*) [Soln]
On Mon, Oct 03, 2005 at 11:55:28AM -0500, Eric Schuele wrote:
> Hello,
>
> Some time back I posted a question regarding how to determine what
> ports/packages would need to be installed on my machine when I install a
> new (new to the local machine) port.
>
> For example, if I do not presently have openoffice installed... what
> will get installed when I 'make install clean' it? Note that I want the
> differences between what is needed to build/run the port and what is
> already present on the machine.
>
> At the time no one responded with a clear way to do this... so I finally
> had a few minutes to write a script to do it for me. I thought someone
> else might find it useful... So I'm posting it here for comments and
> thoughts (be gentle, I'm new to awk).
Here is an improved/spoiled (decide by yourself) version. I aimed to
sport a more orthogonal design and avoid some gotchas I run into (see
comments in awk code).
#! /bin/sh
# Script to determine the differences between what is necessary for
# a port, and what is already present on the local machine.
awkprgt='{
count = 0
pkgs = ""
for(i=5; i<=NF-2; i++) {
pkg = $i
# the "if" is here to hack it around when you get:
# This port requires package(s) "" to build.
if (pkg != "\"\"") {
if (index(pkg, "\"") == 1)
{pkg = substr(pkg, 2, length(pkg)-1)}
if (index(pkg, "\"") > 1)
{pkg = substr(pkg, 1, length(pkg)-1)}
if ( system("pkg_info -e " pkg) == 1) {
pkgs = pkgs " " pkg
count++
}
}
}
if ( count ) {
print "You need the following (%s) perequisites:"
print pkgs
}
else {
print "All (%s) prerequisites are present."
}
}
END {
# triggered, eg., by audio/artswrapper (on my box, at least)
if( ! FNR) {
print "Bogus (empty) %s dependency information"
}
}
'
awkit() {
# Resolve "%s"-s via sed is a blunt hack
# but good enough here and thus we don't have
# to care about the number of occurrences
awk "`echo "$awkprgt" | sed s/%s/$1/g`"
}
make pretty-print-build-depends-list | awkit build
make pretty-print-run-depends-list | awkit run
Alas... while I was making these changes, I succeeded to recall why I
abandoned my earlier attempt to put together a script which fulfils this
(highly desired) functionality.
Because all such scripts are fundamentally broken.
When make decides which ports to pull in, it doesn't only use the flat
data of build and run dependencies, but uses its full Turing complete
computing power. Eg., what happens when a port needs a postscript
interpreter? Should it use the AFPL or the GNU edition as a dependency?
Of course, doing a favor toward one of them (and taking away user's
choice) is unacceptable. So what happens is that make directly checks
whether the gs executable is present.
See, for example, print/gv. Your script's output will include
ghostscript-gnu-7.07_13 both as a build and a run dependency.
Yet when I type make, my ghostscript-gnu-7.07_12 installation will
be happily utilized as the following output snippet shows:
=> Checksum OK for gv-3.6.1.tar.gz.
===> Patching for gv-3.6.1
===> Applying FreeBSD patches for gv-3.6.1
===> gv-3.6.1 depends on executable: gmake - found
===> gv-3.6.1 depends on executable: gs - found
===> gv-3.6.1 depends on shared library: Xaw3d - found
===> gv-3.6.1 depends on shared library: X11.6 - found
===> Configuring for gv-3.6.1
The approach taken by FreeBSD's ports is to have more flexibility but
less predictability, and now we have to live with it. Maybe the Gentoo
guys are the ones who succeeded to find the proper balance between these
two quantities -- they made up a mini-markup-language for denoting
dependencies, which is clever enough to cover all cases but it's still
just an easy to parse flat data.
One solution for FreeBSD could be digging deep into the make backend of
the ports framework and insert the necessary hooks everywhere to produce
a reliable dry-run.
Or severely refactor the whole ports framework and switch to Gentoo style
dependency handling. This won't happen any soon IMHO as ports API
changes should be pushed through all ports...
(OFF: to have a bit of bitter laugh, I think Gentoo's portage suffers
from a fundamental design flaw: they can't tune installation prefixes
(which would be necessary to make it an acceptable cross platform 3rd
party package manager, akin to pkgsrc, but it would have other uses, too).
This is again such a thing which can be changed only by rewriting all of
their e-builds.)
Regards,
Csaba
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To uns
Feedback for a closed PR?
Hi! I had some problem with my digicam. I found a PR which described the phenomena and gave a workaround, too. (PR i386/76653, see http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/76653 ). As I see, feedback was asked for but it didn't come... hence finally the PR has been closed. Now I have the information which could give the requested feedback... What am I to do? The PR Handling Guidelines (http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pr-guidelines/) doesn't cover this case... More precisely, it says that if a "problem is not being worked on, due to lack of information or resources", then it should be suspended, not closed (so I find it strange that this PR has been closed). Regards, Csaba ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Feedback for a closed PR?
On Tue, Oct 04, 2005 at 04:14:40PM +0300, Giorgos Keramidas wrote: > Either submit a followup to the PR requesting that it's reopened and > adding your feedback at the end of the followup, or submit a new PR > (with a reference to the old one, if you feel that's appropriate). Thanks, I submitted a followup. Csaba ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Determining what a port will install... (more than pretty-print-*) [Soln]
On Tue, Oct 04, 2005 at 11:19:03AM -0500, Eric Schuele wrote: > Csaba Henk wrote: > >Because all such scripts are fundamentally broken. > > > >When make decides which ports to pull in, it doesn't only use the flat > >data of build and run dependencies, but uses its full Turing complete > >computing power. Eg., what happens when a port needs a postscript > >interpreter? > > Then do the pretty-print(s) not provide the useful information they > appear to? I mean, If the above were true then they would have no > value... and should go away. Or do they provide true but incomplete > information? As far as I can see, they tell you the list of packages which would be installed if you were doing the install from scratch (ie., no packages were installed). This is a somewhat useful information, anyway. Btw., is make really Turing complete? As far as I can see, complex tasks are delegated to shell, but I can't recall seeing any "while" in make code... > >Should it use the AFPL or the GNU edition as a dependency? > >Of course, doing a favor toward one of them (and taking away user's > >choice) is unacceptable. So what happens is that make directly checks > >whether the gs executable is present. > > > >See, for example, print/gv. Your script's output will include > >ghostscript-gnu-7.07_13 both as a build and a run dependency. > >Yet when I type make, my ghostscript-gnu-7.07_12 installation will > >be happily utilized as the following output snippet shows: > > Is this not acceptable behavior since it is just a port revision? > Shouldn't the revision be compatible in every way with the vendor's release? What do you mean by this? The behaviour seen upon installing gv is absolutely what one would expect. It's just hard to make proper predictions. > Thanks for contributing to the script. You are welcome. Regards, Csaba ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
