Re: Binding amanda to specific interface
[ On Sunday, February 23, 2003 at 23:14:37 (-0500), Mark Radabaugh wrote: ] Subject: Binding amanda to specific interface I'm trying to run Amanda on FreeBSD on a machine with multiple IP's bound to the ethernet interface. Amanda seems to insist on picking the alias interface rather than the primary interface and there doesn't seem to be a switch to control the behaviour. If you're talking about the listening side, well Amanda itself doesn't listen on any sockets -- that's done by inetd and on FreeBSD you have to have separate inetd instances listening on each different IP#. As for the local addresses chosen for outgoing connections, well normally the kernel makes the right choice depending on your routing table -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Binding amanda to specific interface
[ On Monday, February 24, 2003 at 20:09:07 (-0500), Mark Radabaugh wrote: ] Subject: Re: Binding amanda to specific interface The problem is the forward lookup rather than the reverse DNS. If you give 2 different IP addresses to the same hostname BIND will round-robin the 2 addresses - returning the first address on one query and the second on the next. That still shouldn't be a problem. I ran amanda on a network that was multi-homed with two IP subnets on the same ethernet for a very long time and had no problem with it (using ~/.amandahosts). -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
RE: tcpserver
[ On Monday, February 24, 2003 at 19:36:46 (-0500), Casey Shobe wrote: ] Subject: RE: tcpserver Well, I'm using xinetd as a (hopefully) temporary solution. The security issues are my primary concern for not wanting to use it. I prefer to run everything as a standalone daemon if possible (i.e. sshd, httpd, xfs, etc.). xinetd was easy enough to get working though, and I've currently got Amanda working as a client on my server. I don't know what kind of security you might be talking about, but for most purposes running one master internet daemon to handle all incoming service requests actually has a large number of fairly important security related advantages. I also remember seeing a udpserver (based on tcpserver I think) months ago somewhere, but I'm not sure of it's maturity, and can't seem to find it now. Maturity? What's that got to do with it? There are fundamental conceptual problems with trying to do what TCP Wrappers does with a datagram based server. You have to change your whole way of thinking about these things when you use connection-oriented services or even pseudo-connection style UDP servers. Maturity of fundamentally mis-concieved ideas doesn't help any. :-) If you really want to secure amanda then make sure your border firewalls all block traffic to all the ports where you run Amanda on. You could go one further by building an entirely separate and private subnet with separate physical interfaces to all your important servers and run Amanda only on that private network. That's what I do for my clients. As mentioned, I've got a working setup now, but would be very interested in hearing any possible alternatives to *inetd. The host system is linux. I have a version of *BSD inetd that's been gone over with a fairly fine-toothed comb and which may actually be portable enouch to build and work on linux -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Quick Multiple Tape Question
[ On Wednesday, October 23, 2002 at 11:31:20 (-0400), Joshua Baker-LePain wrote: ] Subject: Re: Quick Multiple Tape Question Err, *can* dump/tar span a single *file* across tapes? I'm not sure. A single filesystem -- sure. But a file? Yes, with dump you should be able to put large files on multiple tape volumes. Most versions of dump/restore can handle multiple volumes (and they always could), and they shouldn't care if a file spans multiple volumes, though it's been some time since I really tested this ability in any implementation. However most versions of tar/pax/cpio/afio should _not_ allow you to span multiple tapes with a single file. The formal definitions of ustar, cpio, and now pax archive formats do not allow for multiple volume support. There are some proprietary formats (maybe even GNU Tar's) which might allow spanning a file across multiple tapes. The issue is that there really must be a header on the second and following tapes, and normally in the tar/ustar/pax/cpio formats a header always starts a new file. So in order to use tar/pax/cpio/afio to archive files larger than a single tape you either have to split large file first into just slightly smaller than tape-sized chunks, or you have to create the archive on disk, then split it into just less than tape-sized chunks and either write each chunk to tape and very very very very carefully label the tapes so that you can read the archive back in in the right order, or then subsquently again use a version of pax or tar or cpio which does support multiple volumes to put the archive chunks onto multiple tapes. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: reply-to in mailing list
[ On Thursday, October 10, 2002 at 07:58:03 (-0700), Jerry wrote: ] Subject: Re: reply-to in mailing list Not to beat a dead horse, but it would be nice to see [amanda-users] in the subject line to make it easier to sort mailing lists. That dead horse had damn well better stay dead. Get a real mail client that can filter on the many already available bits of information in the headers -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Tape technology
[ On Thursday, September 12, 2002 at 10:28:13 (+0200), Brian Jonnes wrote: ] Subject: Re: Tape technology about 1600 USD at the time. Is it as dependable as tape? Time will tell. Can you take it offsite? In a sense, yes, by cycling enough drives thru each slot in the array and letting the raid rebuild Well it wouldn't work well that way, though with a mirror of a pair of mirrors you could remove either underlying pair of mirrored drives, then add a new pair of mirrored drives and re-construct the outer mirror. That way you'd have two copies of the data -- one could go off-site for reduncancy and disaster recovery purposes and one could stay on-site for quick retrieval. Maxtor announced low-priced 320GB drives just the other day I'm not really keen on this idea. Although relative to the price of a DDS drive it is affordable (for just one or two harddrives). My main problem is that the drives will be handled by average users. Hrm. Put the drives in canisters. Good ones add to the cost, but that's the only way you'll be easily able to hot-swap ATA drives anyway. By this point I probably wouldn't be using amanda though -- unless I had disk-full clients that couldn't run rsync. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: hi
[ On Tuesday, September 10, 2002 at 09:14:54 (-0500), Dave Sherohman wrote: ] Subject: Re: hi On Mon, Sep 09, 2002 at 03:46:37PM -0400, Greg A. Woods wrote: I beg to differ. List servers should be no more tolerant of accepting e-mail from known abusers, dial-up/DSL/cable addresses, ITYM ISP DHCP pools. A static IP address is a static IP address, regardless of whether the device's uplink is via T1, ISDN, DSL, cable, modem, or carrier pigeon. You can't assume that someone's a spammer purely based on their physical connection to the network. Did I say static? I don't think I said anything about static IP addresses. You can assume someone is not allowed to make outbound SMTP connections from certain classes of service. ISPs register their dial-up/DSL/cable addresses with the various DNSRBLs specifically so third parties can block their users connections. Of course an increasing number of ISPs are simply blocking or proxying all outbound SMTP connections from such classes of users anyway, which they should have done right from the start, but until they all do such blocking or proxying it is necessary for concientious postmasters to block connections from addresses listed in those DNSRBLs. No, I don't think so. All postings to un-moderated lists like this should be only from validated subscribers. Interested users can subscribe just long enough to discuss their issues if they don't want to remain subscribed. And receive how many dozens/hundreds of unrelated messages from the list over the course of a few days while discussing and resolving their issues? Sorry, can't agree with you here. Then they can buy dedicated support from one of the zillions of independent contractors who support free software like Amanda. If users want to get free support for free software then they'd damn well better be prepared to get involved, even if only for a few days. Your attitude is B.S. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
RE: hi
[ On Tuesday, September 10, 2002 at 16:08:22 (+0100), Spicer, Kevin wrote: ] Subject: RE: hi One possibility is to allow anonymous users to post through a web page, but only list members to post via email. If a non-member attempts to post via email they should recieve a polite bounce referring them to the website. Web front-ends to allow sending of e-mail via http are a growing problem, not just because lots of spamware now is programmed to abuse them, but also for other issues. You can't trust the origins of any e-mail received from such a gateway. However your suggestion is not without merit. Perhaps if the bounce included a one-time (or short-lived) password for the HTTP/SMTP gateway -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Spam's a sacrific, at least there's no viruses.
[ On Tuesday, September 10, 2002 at 14:04:58 (-0400), Gene Heskett wrote: ] Subject: Re: Spam's a sacrific, at least there's no viruses. Its a fact of life these days, and one sets up filtering accordingly using whatever facilities are available on ones own platform. There's no reason not to emply the same kinds of controls on any list server as one could employ on ones own platform. Indeed there's every reason to do so. It saves everyone from additional irritation and it saves everyone's bandwidth. Not only that but some controls can only be implemented on the first hop -- i.e. at the point where the spammer first injects the message, and that's the list server. Attempts to filter after that point all go downhill in effectiveness. Open list servers are very nearly as bad as open relays. The only thing that keeps them from being as bad is that they don't give 100% control over to the spammer -- people can unsubscribe from the list(s) to avoid the spam, whereas the only way to block spam from open relays is to very agressively test for them and to block _all_ email from them. Now, lets get this list back on topic, which is amanda support and education. This meta topic is entirely on topic for this list because this list is still passing spam unhindered to all subscribers. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Spam's a sacrific, at least there's no viruses.
[ On Tuesday, September 10, 2002 at 13:09:36 (-0500), Frank Smith wrote: ] Subject: Re: Spam's a sacrific, at least there's no viruses. Some general observations on this and previous related threads: Amanda is free software. The amanda-users mailing list is free. Someone (not me) administers the list and pays for it. When someone gets something for free, they can suggest changes to the person(s) responsible for providing it. The person(s) giving things away are not obligated to make any requested changes, but may if they choose, and public opinion may or may not be a factor in that decision. If suggestions aren't taken, accept the fact that not everyone's opinions and priorities are the same. Everything in life has pros and cons, mailing lists are no exception. No list will fit everyone's needs. Subscribe to the one's that best fit your needs, unsubscribe from the ones that don't. If anyone knows how to run the perfect mailing list, they should start one and show the world how its done. Agreed on all points. ;-) -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: sites using amanda - possible survey
[ On Sunday, August 25, 2002 at 12:54:22 (-0500), Brandon D. Valentine wrote: ] Subject: Re: sites using amanda - possible survey On Sun, 25 Aug 2002, Jon LaBadie wrote: I've not seen a survey done in this mailing list, but I wonder if one would be appropriate to get a reasonable answer to this question. Then we could put a as of date XYZ, amanda was known to be in use in these organizations into the F-O-M. I did this several months ago: http://amanda.sourceforge.net/fom-serve/cache/319.html good start, but I really don't like thos F-O-M things and would never go to the trouble of getting an ID so I could submit stuff to one. (an open WIKI, on the other hand) I'd like it if more people would add their organizations to the list but I can only spend so much time prodding this forum. ;-) Why spend any time beyond that required for the first message? That's what cron is for! :-) -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: sites using amanda - possible survey
[ On Monday, August 26, 2002 at 21:59:07 (+0200), Toni Schlichting wrote: ] Subject: Re: sites using amanda - possible survey This finally lead to an entry in my list. What do you think about the idea to contact all the admins who placed those nice statements on the web-sites, to make them enter their project into F-O-M? Well, as such an admin who could be convinced to put a nice statement on a web site about some free software I might use, I can say with certainty that _I_ would not be convinved to enter my own information into any F-O-M web thingy, though I wmight easily grant permission for someone else to do so on my behalf. I.e. these things _REALLY_ need live human editors and/or maintainers. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: META mailing list policy....
[ On Tuesday, August 13, 2002 at 11:34:23 (-0400), Todd Kover wrote: ] Subject: Re: Free Adult Movies There are some spam constraints in place. One of the biggest ones that's not in there is restriction of posting to the list to members-only. Generally, amanda-users sees about 50% of it's traffic from non-members. Perhaps there should be an amanda-bugs and/or amanda-info list(s) which are open to non-members and amanda-users should be for members only. That way new users could post bug reports and request basic info, etc., and the regular crowd could avoid most (or at least more) spam. Real people need not even subscribe to the open lists -- the bug reports could be filtered and forwarded to a mail gateway for the bug tracking system on sourceforge, and the info list could basically be a semi-smart autoresponder. I see a similar amount of spam on other lists I'm on that are as old as amanda-users. I'd say amanda-users is better than many other open lists, but then again I've unsubscribed to many other open lists because of spam problems :-) How many subscribers are there now? -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Restoring /
[ On Tuesday, July 23, 2002 at 15:18:05 (-0500), C. Chan wrote: ] Subject: Re: Restoring / Also Sprach Greg A. Woods: There's nothing religious about it, at least not since Elizabeth Zwicky published her study of the reliability and capabilities of various backup programs. Elizabeth Zwicky, Torture-testing Backup and Archive Programs: Things You Ought to Know But Probably Would Rather Not, LISA V proceedings, San Diego, 1991, pp. 181-185. Note the date: 1991. Some things have changed then, like the introduction of journaled filesystems, snapshotting, ACLs, and so on. It's still worth reading but please look at the version numbers of the utilities under review. I'd welcome any references to a more recent review on the same topic. The point is that there's no religion about this issue any more. If you're not using the systems already tested and described in the paper then you get the tools (they're still available too, though they are also realtively easily reproduce using the descriptions in the paper) and you test what you have. The results should be entirely scientific (unless you deviate in your procedures and mess up your measurements). -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Exabyte eliant vs 85xx
[ On Tuesday, July 23, 2002 at 09:21:49 (+0200), Gerhard den Hollander wrote: ] Subject: Exabyte eliant vs 85xx This is slightly off-topic, but does anyone know if the new(er) exabyte eliant drives are read/write compatible with the 85xx (specific the 8505) series ? Yes, they work just fine reading tapes from 82xx and 85xx series drives, and they can write tapes readable on the 8500, 8505, and their compressed modes. The Eliant 820 really is just a modernized and faster 8505. Specifically the Eliant 820 drive can read the 8200 and 8500 and 8500c tape formats, and it can write the 8500 and 8500c tape formats. Note that 8200 formatted tapes are ejected again if they are not physically write-protected. I'm reasonably certain you can still download all the manuals from: http://www.exabyte.com/support/online/documentation/techpubs.cfm -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Restoring /
[ On Tuesday, July 23, 2002 at 11:58:13 (-0400), Joshua Baker-LePain wrote: ] Subject: Re: Restoring / Note that I have no idea how well tar will do restoring / on Solaris, i.e. I don't know that you'll get a functional OS. You may want to use ufsdump -- the dump horror stories to which you refer mainly deal with Linux. But, this is somewhat religious, so use what works for you. There's nothing religious about it, at least not since Elizabeth Zwicky published her study of the reliability and capabilities of various backup programs. Elizabeth Zwicky, Torture-testing Backup and Archive Programs: Things You Ought to Know But Probably Would Rather Not, LISA V proceedings, San Diego, 1991, pp. 181-185. Unfortunately it is not available from Usenix/SAGE online but unofficial archive copies are here: http://berdmann.dyndns.org/zwicky/testdump.doc.html http://gd.tuwien.ac.at/utils/archivers/star/testscripts/zwicky/testdump.doc.htm See also: http://www.usenix.org/publications/login/1998-4/reliability.html As for Linux brain damage, well, that's not very religious either. Dump is broken for mounted filesystems and Linux 2.4 kernels -- end of story. Unmount your filesystems before backing them up, and go single user and cross your fingers to backup your root filesystems! -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Backing up PostgreSQL?
[ On Friday, June 21, 2002 at 18:37:20 (+0100), Paul Jakma wrote: ] Subject: Re: Backing up PostgreSQL? On Thu, 20 Jun 2002, Greg A. Woods wrote: Where does it say that close/open will flush metadata? That's how the unix filesystem works. UTSL. that's an implementation issue - you cant rely on it. Apparently you can on anything but linux, and I'm rather stunned by the situation with the latter -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Backing up PostgreSQL?
[ On Friday, June 21, 2002 at 18:15:28 (+0100), Paul Jakma wrote: ] Subject: Re: Backing up PostgreSQL? On Fri, 14 Jun 2002, Greg A. Woods wrote: That's irrelevant from PostgreSQL's point of view. There's no sure way to tell the postgresql process(es) to make the on-disk database image consistent before you create the snapshot. if it's pg 7.1+ then it has write-ahead-logging, and the on-disk state /is/ guaranteed to be recoverable to a consistent state. in which case snapshot+backup of snapshot is a valid way to backup pgsql. Yes, I agree with this, assuming you're talking about an increment to the currently available release that puts you up ahead to some mythical future vapour-ware. The ability to reliably restore consistency in such a backup copy of the files not only depends on write-ahead-logging support, but also on properly functioning REDO _and_ UNDO functions. Note though that currently the UNDO operation is currently still unimplemented in PostgreSQL-7.2.1 -- thus my original concern, and along with other issues why I say that pg_dump really is the only best way to do a backup of a pgsql database. I.e. PostgreSQL releases up to, and including, 7.2.1 do not provide a way to guarantee a database is always recoverable to a consistent state. Current releases do not have a built-in way to remove changes already made to data pages by uncomitted transactions. From what I've read and heard from pgsql developers you sholdn't hold your breath for this feature either -- it probably requires a re-design of the W.A.L. internals to realise in any reasonable implementation. When you restore a database from backups you really do want to just immediately start the database engine and know that the restored files have full integrity. You realy don't want to have to rely on W.A.L. When you restore a database from backups during a really bad disaster recovery procedure you sometimes don't even want to have to depend on the on-disk-file format being the same. You want to be able to load the data into an arbitrary version of the software on an arbitrary platform. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Backing up PostgreSQL?
[ On Friday, June 21, 2002 at 18:00:19 (-0300), Martín Marqués wrote: ] Subject: Re: Backing up PostgreSQL? On Vie 21 Jun 2002 17:33, Greg A. Woods wrote: [ On Friday, June 21, 2002 at 18:37:20 (+0100), Paul Jakma wrote: ] Subject: Re: Backing up PostgreSQL? On Thu, 20 Jun 2002, Greg A. Woods wrote: Where does it say that close/open will flush metadata? That's how the unix filesystem works. UTSL. that's an implementation issue - you cant rely on it. Apparently you can on anything but linux, and I'm rather stunned by the situation with the latter Other UNIX? If you could rely on it, why does Informix (and other database servers, but this is the one I used) still use it's own FS to write the database files? Because there are tremendous performance advantages to using RAW I/O if you're prepared to go to the trouble of dealing with all the niggling details (some of these advantages are supposedly less visible on modern hardware and modern systems, but they sure as heck were plainly visible even a few years ago) -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Backing up PostgreSQL?
[ On Saturday, June 22, 2002 at 00:07:05 (+0200), Ragnar Kjørstad wrote: ] Subject: Re: Backing up PostgreSQL? On Fri, Jun 21, 2002 at 05:17:35PM -0400, Greg A. Woods wrote: Yes, I agree with this, assuming you're talking about an increment to the currently available release that puts you up ahead to some mythical future vapour-ware. The ability to reliably restore consistency in such a backup copy of the files not only depends on write-ahead-logging support, but also on properly functioning REDO _and_ UNDO functions. It should only require REDO. No changes are made to the actual database-files until the transaction is commited, written to the WAL and fsynced. At this point there is no longer a need for UNDO. Hmmm possibly. I'm not that intimately familiar with the current WAL implementation, though what I have stated comes directly from the 7.2.1 manual. If I'm wrong then so is the manual. :-) But it doesn't do changes to the data-pages until the transaction is commited. If it had; your database would have been toast if you lost power. (or at least not correct) And so I assume it could be -- and so the manual claims it could be too As I read it the manual claims the future implementation of UNDO will have the future benefit of avoiding this danger. When you restore a database from backups you really do want to just immediately start the database engine and know that the restored files have full integrity. You realy don't want to have to rely on W.A.L. I really don't see why relying on WAL is any different from relying on other postgresql features - and it is hard to run a postgresql database without relying on postgresql well, the WAL implementation is new, acknowledged to be incomplete, and so far as I can tell requires additional work on startup Indeed re-loading a pg_dump will take lots more time, but that's why I want my DB backups to be done both as a ready-to-roll set of file images as well as a pg_dump :-) When you restore a database from backups during a really bad disaster recovery procedure you sometimes don't even want to have to depend on the on-disk-file format being the same. You want to be able to load the data into an arbitrary version of the software on an arbitrary platform. Yes; unfortenately this is not even possible with pg_dump. (it is better than a filesystem backup in this regard, but there are still version-incompabilities that have to be fixed manually) Indeed -- but so goes the entire world of computing! ;-) -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Backing up PostgreSQL?
[ On Friday, June 21, 2002 at 23:59:27 (+0200), Ragnar Kjørstad wrote: ] Subject: Re: Backing up PostgreSQL? Remember I've only been talking about the backed up files being in a self-consistent state and not requiring roll-back or roll-forward of any transaction logs after restore. If you don't want your database to do roll-back or roll-forward backup-snapshots will work for you. Neither will power-failures. And in theory a clean shutdown could also leave the database in a state where it required roll-forward on restart, but my guess is that's not the case. Actually I'd assume the opposite -- that even a clean shutdown of the engine could leave an uncommitted transaction in the database image and thus might require a log UNDO (not a log REDO). The difficulty of course being those pesky long-running transactions, and the fact that you can't always shut down the clients first (and thus hopefully trigger a proper undo of the open transactions before the database engine itself is shut down). There are no writes to the filesystem at all while the snapshot is in progress. The LVM-driver will block all data-access until it is completed. If not, it wouldn't be a snapshot, would it? I realize that -- but it doesn't mean the snapshot couldn't begin between two inter-related writes to two separate files (or even two separate but inter-related writes to two separate pages in the same file). If both writes are necessary to result in a consistent DB then the snapshot will necessarily be inconsistent by definition. If you want the snapshot to be in a self-consistent state you have to somehow pause the database at a point where there are no open transactions and make sure the database engine has issued writes for every bit of data for all committed transactions (and potentially even that it has closed all its open files so that FS metadata is also updated). The best way to do this seems to be to shut down the DB engine, and it's certainly the only application-independent procedure I can think of. Huh? Why would you want a seperate backup of the database transaction log? The log is stored in a file together with the rest of the database, and will be included in the snapshot and the backup. Yeah, but I'm assuming that I'll have to manually UNDO any uncommitted transactions, as per the 7.2.1 manual. If you didn't backup the transaction-log at the exact same time you backed up the rest of the files it would not work - it would be inconsistent and there could be data missing. indeed -- however I've been trying to think of a way to find open transactions in an incomplete transaction log. If an open transaction was not opened in the current log then I've got to look for it to be closed to know that it was incomplete (and thus needs to be undone) at the time the FS snapshot was taken. I was probably barking up the wrong tree with that idea though -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Backing up PostgreSQL?
[ On Wednesday, June 19, 2002 at 23:53:14 (+0200), Ragnar Kjørstad wrote: ] Subject: Re: Backing up PostgreSQL? By this definition postgresql is consistant at all times That's simply not possible to be true. PostgreSQL uses multiple files in the filesystem namespace to contain its data -- sometimes even multiple files per table. It is literally impossible, with the POSIX file I/O interfaces, to guarantee that concurrent writes to multiple files will all complete at the same time. Remember I've only been talking about the backed up files being in a self-consistent state and not requiring roll-back or roll-forward of any transaction logs after restore. Not at all. There are multiple levels of consistancy and in order to be safe from corruption you need to think of all of them. The WAL protects you from database inconsistancies, the journaling filesystem from filesystem inconsistancies and a if the RAID is doing write-back caching it must have battery-backed cached. Yeah, but you are still making invalid claims about what those different levels of consistency imply w.r.t. the consistency of backed up copies of the database files. No, normal unix filesystems doesn't provide enough consistency, unless you're happy with a system that will come back up most times. Files are created and appended to, and there will be times where the filesystem is inconsistant. I think you need to learn a bit more about how PostgreSQL uses the filesystem, and how the Unix filesystem guarantees with ordered metadata writes that consistency can be properly regained after any crash. Only hardware design flaws, or loss of data between crash and reboot, can screw it up. Where does it say that close/open will flush metadata? That's how the unix filesystem works. UTSL. If you read my posts carefully you will find that I've never claimed that filesystem consistency equals database consistency. You have. You have confused the meanings and implied that one will get you the other. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Backing up PostgreSQL?
[ On Thursday, June 20, 2002 at 22:17:55 (+0200), Ragnar Kjørstad wrote: ] Subject: Re: Backing up PostgreSQL? On Thu, Jun 20, 2002 at 01:11:09PM -0400, Greg A. Woods wrote: [ On Wednesday, June 19, 2002 at 23:53:14 (+0200), Ragnar Kjørstad wrote: ] Subject: Re: Backing up PostgreSQL? By this definition postgresql is consistant at all times That's simply not possible to be true. PostgreSQL uses multiple files in the filesystem namespace to contain its data -- sometimes even multiple files per table. It is literally impossible, with the POSIX file I/O interfaces, to guarantee that concurrent writes to multiple files will all complete at the same time. Remember I've only been talking about the backed up files being in a self-consistent state and not requiring roll-back or roll-forward of any transaction logs after restore. Puh - we've been through this already! Postgresql doesn't need this guarantee, because it writes to it's log to avoid this very problem! You haven't been paying attention to what I've been saying: Remember I've only been talking about the backed up files being in a self-consistent state and not requiring roll-back or roll-forward of any transaction logs after restore. In order to have consistent (from a database and application perspective) files on a filesystem backup of the database files, you MUST -- ABSOLUTELY MUST -- find some mechanism to synchronise between the database and the filesystem for the duration of the time it takes to make the filesystem backp, whether thats the few seconds it takes to create a snapshot, or the many minutes it takes to make a verbatim backup using 'dump' or whatever. If all contingencies are to be covered the only sure way to do this is to shut down the database engine and ensure it has closed all of its files. There must be no writes to the filesystem by the database process(es) during the time the backup or snapshot being made. None. Not to the database files, nor to the transaction log. None whatsoever. With great care and a separate backup of the database transaction log taken after the filesystem backup it may be possible to re-build database consistency after a restore, but I wouldn't ever want to risk having to do that in a disaster recovery scenario. I would either want a guaranteed self-consistent filesystem copy of the database files, or a properly co-ordinated pg_dump of the database contents (and preferrably I want both, and both representing the exact same state, though here there's more leeway for using a transaction log to record db state changes between one form of backup and the other :-) In the end if your DBA and/or developers have not taken into account the need to shut down the database for at least a short time on a regular basis in order to obtain good backups then you may have more serious problems on your hands (and you should find a new and more experienced DBA too! ;-). The literature is full of ways of making secure backups of transactions -- but such techniques need to be considered in the design of your systems. For example it's not unheard of in financial applications to run the transaction log direct to a hardware-mirrored tape drive, pausing the database engine (but not stopping it) only long enough to change tapes, and immediately couriering one tape to a secure off-site location. Full backups with the database shut down are then taken only on much longer intervals and disaster recovery involves replaying all the transactions since the last full backup. There are also tricks you can play with RAID-1 which are much faster and potentially safer than OS-level filesystem snapshots (and of course such tricks don't require snapshot support, which is still relatively rare and unproven in many of the systems where it is available). These tricks allow you to get away with shutting down the database only so long as it takes to swap the mirror disk from one set to another, at which point you can make a leisurely backup of the quiescent side of the mirror. Then the RAID hardware can do the reconstruction of the mirror while the database remains live. Here is the close-code on linux: As far as I know the Linux kernel does not have support for anything quite exactly resembling the Unix filesystem. Your analysis of the code you quoted would seem to confirm that too. :-) Just to make sure there is no (additional) confusion here; what I'm saying is: 1. Meta-data must be updated properly. This is obvious and shouldn't require futher explanation... 2. non-journaling filesystems (e.g. ext2 on linux) do update the inode-metadata on fsync(), but they do not update the directory. The Unix Fast File System is not a log/journaling filesystem. However it does not suffer the problems you're worried about. Wasn't this question originally about FreeBSD anyway? -- Greg A. Woods +1 416 218
Re: Backing up PostgreSQL?
there are potentially performance related reasons to avoid journaling filesystems! I've heard people claim they are just as fast with PostgreSQL, and some even have claimed performance improvements, but none of the claimants could give a scientific description of their benchmark and I'm pretty sure they were seeing artifacts, not a representation of real-world throughput. If you haven't seen the scientific description of this you haven't looked hard enough. (check out the reiserfs mailinglist archive, for instance) I understand journaling filesystems quite well thank you. I do not understand at all how any of those making claims for pgsql's performance on such such filesystems have done their benchmarks. As for benchmarks that demonstrate this effect, try running postmark on both a journaling and non-journaling filesystem (preferably the same with journaling enabled/disabled). I doubt the effect is visable in database-benchmarks, as databases update data very frequently compared to metadata. Indeed postmark is definitely not a terrific benchmark for pgsql. However a pgsql application could be a good benchmark for pgsql. There are other advantages of snapshot-backups in addition to the recovery-time: * space-saving (no need for temporary space for the pg_dump) (unless there are lots of writes going on, of course) You're assuming you'll always be doing recovery to the same system, no? * generality This approach works for _all_ applications, not just databases * consistancies between multiple databases (AFAIK the pg_dumpall doesn't take an atomic dump of all databases, so if you have a weird frontend that uses multiple databases and expect them to be consistant) This is _still_ a bogus claim, and always will be. Filesystem consistency does not equal database consistency (at least not when the db is stored in multiple files in the filesystem and there are any consistency constraints between two or more of those files). You must force a syncronisation point between your database(s) and your backup mechanism, whatever that may be. A filesystem snapshot alone does not do that. * No additional CPU-load on the database-server Where do the resources necessary for taking the snapshot and backing it up come from then? Thin air? -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Backing up PostgreSQL?
[ On Saturday, June 15, 2002 at 14:42:35 (+0200), Ragnar Kjørstad wrote: ] Subject: Re: Backing up PostgreSQL? On Fri, Jun 14, 2002 at 09:15:15PM -0400, Greg A. Woods wrote: [ On Saturday, June 15, 2002 at 00:45:12 (+0200), Ragnar Kjørstad wrote: ] Subject: Re: Backing up PostgreSQL? snapshots (LVM snapshots) are not supposedly nearly instantaneous, but instantaneous. All write-access to the device is _locked_ while the snapshot is in progress (the process takes a few milliseconds, maybe a second on a big system), and there are _no_ races. That's the whole point of the snapshot! That's irrelevant from PostgreSQL's point of view. There's no sure way to tell the postgresql process(es) to make the on-disk database image consistent before you create the snapshot. The race condition is between the user-level process and the filesystem. The only sure way to guarantee a self-consistent backup is to shut down the process so as to ensure all the files it had open are now closed. PostgreSQL makes no claims that all data necessary to present a continually consistent view of the DB will be written in a single system call. In fact this is impossible since the average database consistes of many files and you can only write to one file at a time through the UNIX system interface. Yes it does, and no it's not impossible. see http://www.postgresql.org/idocs/index.php?wal.html Sorry but you're not talking about what I'm talking about. Yes WAL will give you a means to hopefully recover a restored database into a consistent view. It will NOT, and cannot possibly, guarantee the consistency of many files on the disk, not even with fsync() (though PostgreSQL does try very hard to order it's own metadata writes -- but that's not the point and it's still irrelevant to the question). Unless you can do a global database lock at a point where there are no open transactions and no uncommitted data in-core, the only way to guarantee a consistent database on disk is to close all the database files. Even then if you're very paranoid and worried about a hard crash at a critical point during the snapshot operation you'll want to first flush all OS buffers too, which means first unmounting and then remounting the filesystem(s) (and possibly even doing whatever is necessary to flush buffers in your hardware RAID system). It really_ is best to just use pg_dump and back up the result. Stopping the database means closing all the connections, and if you have multiple applications doing long overlapping transactions that don't recover well from shutting down the database, then you have a problem. I agree, however this is an operational problem, not a technical problem. If you choose to use filesystem backups for your database then you need to have a very clear and deep understanding of these issues. It really Really is best to just use pg_dump and back up the result. The newest release of postgresql always use fsync (on it's log) unless you specificly turn it off. You shouldn't do that if you care about your data. I agree, but we're not discussing what you and I do, but rather what random John Doe DBA does. There's ample quantity of suggestion out in the world already that makes it possible he will turn off fsync for performance reasons The only requirement on the filesystem is that it is journaling as well, so it's always kept in a consistant state like the postgresql-database is.. Now you're getting a little out of hand. A journaling filesystem is a piling of one set of warts ontop of another. Now you've got a situation where even though the filesystem might be 100% consistent even after a catastrophic crash, the database won't be. There's no need to use a journaling filesystem with PostgreSQL (particularly if you use a proper hardware RAID subsystem with either full mirroring or full level 5 protection). Indeed there are potentially performance related reasons to avoid journaling filesystems! I've heard people claim they are just as fast with PostgreSQL, and some even have claimed performance improvements, but none of the claimants could give a scientific description of their benchmark and I'm pretty sure they were seeing artifacts, not a representation of real-world throughput. Restoring a snapshot is the fastest possible way of getting the system back online, and even a tape-backup of the snapshot will be faster than importing the database. This is true. However before you give that fact 100% weight in your decision process you need to do a lot more risk assessment and disaster planning to understand whether or not the tradeoffs inherent will not take away from your real needs. I still believe it really Really REALY is best to just use pg_dump and back up the result. If the time to reload a dump is a major concern to you then you have other far more critical issues to deal with before you can make a sane choice about backup integrity and disaster
Re: Backing up PostgreSQL?
[ On , June 14, 2002 at 09:23:33 (-0500), Kirk Strauser wrote: ] Subject: Re: Backing up PostgreSQL? At 2002-06-14T07:41:53Z, Ragnar Kjørstad [EMAIL PROTECTED] writes: Hmm, is the pg_dump consistent? From man 1 pg_dump: pg_dump makes consistent backups even if the database is being used concurrently. pg_dump does not block other users accessing the database (readers or writers). I believe a caveat is necessary -- the reliability of this feature depends on which version of PostgreSQL you're using -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Backing up PostgreSQL?
[ On , June 13, 2002 at 22:29:33 (-0500), Kirk Strauser wrote: ] Subject: Re: Backing up PostgreSQL? At 2002-06-13T23:07:54Z, Niall O Broin [EMAIL PROTECTED] writes: Nothing to do with BSD, Linux, or even, Gawd help us, Windows. If you don't take the database offline then the files which make up the database are not guaranteed to be in anything resembling a consistent state i.e. if you copy those files, in whatever manner, there's absolutely no guarantee that you'll be later able to use the database program to read the files. That's the really nice thing about FreeBSD's new snapshots (in the development tree). When you freeze the filesystem image, it really is a snapshot. If all of your database files are on the same filesystem then you're pretty much guaranteed a consistent backup, regardless of the amount of updates being committed to the database. Which is still really totally useless for backing up an RDBMS like PostgreSQL. Even if everything is fsync()ed all the time there's still going to be dozens of race conditions where a backup, even if supposedly nearly instantaneous like a snapshot, will result in an inconsistent database image. With PostgreSQL in particular (since it only uses filesystem files, not raw disk) you MUST stop the database -- i.e. completely stop the processes that have database files open so that those files are completely all closed and so that the kernel filesystem interface can present a consistent view of the data that's been written to the filesystem. This is becoming even more critical as PostgreSQL gains ever more features that allow the DBA to optimise when writes are done to the filesystem. The only good thing about filesystem snapshots is that you can in theory do them much quicker (than a full dump) so database downtime is much lower. I would re-do the backup steps as 0) Stop the database 1) Make a snapshot 1.5) restart the database 2) Use dump to back up that completely static filesystem image /^\ a level zero 3) Remove the snapshot Of course if you're concerned about the integrity of your data (and perhaps you give your data a higher value than even the application and support system it is stored and manipulated in), particularly for off-site backups, then the only really sure way to backup the database is to do a dump at the database level into a flat-file form, and of course PostgreSQL has pg_dump which has already been discussed. You should probably be doing regular pg_dumps anyway, even if you don't do them every time you run amanda. They're the only way you can be sure your disaster recovery plan works -- i.e. they let you reload a new test database to be sure everything works. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
RE: Backing up PostgreSQL?
[ On Friday, June 14, 2002 at 12:20:21 (-0400), Bort, Paul wrote: ] Subject: RE: Backing up PostgreSQL? I don't know much about PostgresQL, but on MS SQL server and Oracle (IIRC), any update that would leave the database inconsistent should be inside a transaction. Any snapshot will not happen while a transaction is in progress; therefore the snapshot is consistent and restorable. I guess it depends on how sane your programmers are. Oracle, running on any snapshot-capable unix (including FreeBSD) and using a normal filesystem for storage, will not -- cannot possibly -- guarantee that a snapshot will not happen while a transaction is in progress. There is no possible interlock in any snapshot implementations I'm aware of between the kernel (which does the snapshot operation) and the user-land Oracle process(es). -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
RE: Backing up PostgreSQL?
[ On Friday, June 14, 2002 at 15:07:40 (-0400), Bort, Paul wrote: ] Subject: RE: Backing up PostgreSQL? Sorry, when the previous poster mentioned 'snapshot', I was thinking of SQL Server's 'dump', which is transactionally consistent, because it's done by the SQL engine. I thought Oracle had a similar method for producing a usable backup of the SQL server? yes, I believe Oracle also has a database dump utility even when using filesystem storage (it certainly does when raw disk is used for storage and I see no logical reason why the same tool wouldn't work for all storage mechanisms, but then again we are talking about Oracle! :-) -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Backing up PostgreSQL?
[ On Saturday, June 15, 2002 at 00:45:12 (+0200), Ragnar Kjørstad wrote: ] Subject: Re: Backing up PostgreSQL? snapshots (LVM snapshots) are not supposedly nearly instantaneous, but instantaneous. All write-access to the device is _locked_ while the snapshot is in progress (the process takes a few milliseconds, maybe a second on a big system), and there are _no_ races. That's the whole point of the snapshot! That's irrelevant from PostgreSQL's point of view. There's no sure way to tell the postgresql process(es) to make the on-disk database image consistent before you create the snapshot. The race condition is between the user-level process and the filesystem. The only sure way to guarantee a self-consistent backup is to shut down the process so as to ensure all the files it had open are now closed. PostgreSQL makes no claims that all data necessary to present a continually consistent view of the DB will be written in a single system call. In fact this is impossible since the average database consistes of many files and you can only write to one file at a time through the UNIX system interface. If your snapshot occurs between two writes where both are necessary to maintain DB consistency then the snapshot is in an inconsistent state. Yes there are other ways to recover consistency using other protection mechanisms maintained by PostgreSQL, but you don't want to be relying on those when you're doing backups -- you barely want to rely on those when you're doing crash recovery! If doing a snapshot really is that fast then there's almost no excuse _not_ to stop the DB -- just do it! Your DB downtime will not be noticable. To postgresql (or any other application) the rollback of an snapshot (or the backup of a snapshot) will be exactly like recovering from a crash. Database-servers need to write the data to disk (and fsync) before the transaction is completed. In practise they don't actually write it to the database-files but to a log, but that doesn't change the point. So, the only advantage of shutting down the database is that it doesn't have to recover like from a crash. Newer releases of PostgreSQL don't always use fsync(). I wouldn't trust recovery to be consistent without any loss implicitly. Because PostgreSQL uses the filesystem (and not raw disk) the only way to be 100% certain that what's written to disk is a consistent view of the DB is to close all the open DB files. You don't want the state of your backups to appear as if the system had crashed -- you want them to be fully self-consistent. At least that's what you want if you care about your data _and_ your application, and you care about getting a restored system back online ASAP. Of course if you really care most about your data in and of itself then you'll be doing pg_dump to back it up -- quick restoration of a given physical system isn't always what's most important! Maybe both are important -- do a pg_dump, back up the dump file, then stop the DB, do a snapshot, restart the DB, and then back up the snapshot too. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: dump fails with bread and lseek trouble
[ On Saturday, December 15, 2001 at 12:40:56 (+0100), Christoph Scheeder wrote: ] Subject: Re: dump fails with bread and lseek trouble This pops up every few weeks here on the list, its very simple: you are backing up an active filesystem with a tool designed primary for backing up filesystems mounted read-only. or not mounted at all! ;-) -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
