Move disk without loosing backup history?
I've just moved a disk from one server to another without really changing anything with respect to how the clients see it; logically, the disk still represents exactly the same volume on the network. Is there any way I can change the amanda config so that the disk is backed up via the new server, but status is written to the existing backup history of the volume? I originally planned to use hostname aliases in such a way that no config update would be necessary in this situation, but as you know, Amanda doesn't really understand the alias concept (or didn't when I first configured it, anyway)... - Toralf
Re: Move disk without loosing backup history?
On Thursday 28 August 2008, Toralf Lund wrote: I've just moved a disk from one server to another without really changing anything with respect to how the clients see it; logically, the disk still represents exactly the same volume on the network. Is there any way I can change the amanda config so that the disk is backed up via the new server, but status is written to the existing backup history of the volume? I originally planned to use hostname aliases in such a way that no config update would be necessary in this situation, but as you know, Amanda doesn't really understand the alias concept (or didn't when I first configured it, anyway)... - Toralf Unforch, what I'd call a bug in tar will cause it to be treated as a new device. Part of tar's detection code makes the device's assigned number part of the new/old decision. So it will be subjected to a full level 0 backup as a newly discovered disk. The tar folks at gnu do not consider that a bug, but as a part of the security. Amanda will recover, and resume doing backups normally once the initial level 0 is done. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) He has shown you, o man, what is good. And what does the Lord ask of you, but to do justice, and to love kindness, and to walk humbly before your God?
Re: Move disk without loosing backup history?
Gene Heskett wrote: On Thursday 28 August 2008, Toralf Lund wrote: I've just moved a disk from one server to another without really changing anything with respect to how the clients see it; logically, the disk still represents exactly the same volume on the network. [... ] Unforch, what I'd call a bug in tar will cause it to be treated as a new device. Part of tar's detection code makes the device's assigned number part of the new/old decision. So it will be subjected to a full level 0 backup as a newly discovered disk. This is not really a problem. But I don't think I follow you. Perhaps I wasn't clear enough in my original post; the disk is physically the same as before, it's the *host* that has changed. I'd really like the DLE in question to list the actual host it's connected to, and not some client that mounts the volume, so as to avoid sending the same data twice across the network. But if I change the DLE just like that, Amanda will think I'm backing up a new disk (won't it?), so I'll get two separate indexes for what's exactly the same disk, and if I want to recover a really old file, I need to remember to switch to the old index/hostname. Which is something I'd rather avoid. I'm mainly talking about an archival config without tape reuse, by the way. And yes, I do keep amanda indexes from the beginning of time for those, as the way I see it, without these, the tapes would be pretty much useless, since nobody would remember what was supposed to be on them... - Toralf
Re: Move disk without loosing backup history?
Toralf Lund wrote: Gene Heskett wrote: On Thursday 28 August 2008, Toralf Lund wrote: I've just moved a disk from one server to another without really changing anything with respect to how the clients see it; logically, the disk still represents exactly the same volume on the network. [... ] Unforch, what I'd call a bug in tar will cause it to be treated as a new device. Part of tar's detection code makes the device's assigned number part of the new/old decision. So it will be subjected to a full level 0 backup as a newly discovered disk. This is not really a problem. But I don't think I follow you. Perhaps I wasn't clear enough in my original post; the disk is physically the same as before, it's the *host* that has changed. I'd really like the DLE in question to list the actual host it's connected to, and not some client that mounts the volume, so as to avoid sending the same data twice across the network. I suppose I should also point out that the hostname in the DLE is not the one of the host running amdump. I suppose I might have used this for all entries from the beginning, since everything is supposed to be available via NFS (thus using NFS rather than the amanda network protocol to transfer the data), but I didn't really think about it a the time. Maybe I could manipulate the host database so that the hostname would be an alias for the dump host after all, but this might cause conflicts with other DLEs where another alias for that host is listed, and raise some issues not directly related to the amanda config... But if I change the DLE just like that, Amanda will think I'm backing up a new disk (won't it?), so I'll get two separate indexes for what's exactly the same disk, and if I want to recover a really old file, I need to remember to switch to the old index/hostname. Which is something I'd rather avoid. I'm mainly talking about an archival config without tape reuse, by the way. And yes, I do keep amanda indexes from the beginning of time for those, as the way I see it, without these, the tapes would be pretty much useless, since nobody would remember what was supposed to be on them... - Toralf -- Toralf Lund [EMAIL PROTECTED] +47 66 85 51 22 ProCaptura AS +47 66 85 51 00 (switchboard) http://www.procaptura.com/ +47 66 85 51 01 (fax)
Re: Move disk without loosing backup history?
Dustin J. Mitchell wrote: On Thu, Aug 28, 2008 at 7:48 AM, Gene Heskett [EMAIL PROTECTED] wrote: The tar folks at gnu do not consider that a bug, but as a part of the security. To be fair, the tar developers did fix this -- in 1.21, IIRC. As to the original question, no, I don't think that there is any way to pretend that one host/disk is the same as another. When we have a more expressive catalog, it might be interesting to have some kind of redirect that amrecover could follow when browsing the history of a DLE -- similar to Subversion's copy-from. Yes. This is exactly what I think I need. It would also help when setting up new configs if amanda would compare IP addresses rather than hostnames when determining if different DLEs are on the same host. You might then keep disklist containing the_server_for_disk1 /disk1 full-tar the_server_for_disk2 /disk2 full-tar and so on, where the_server_for_disk1 and the_server_for_disk2 are hostname aliases that are moved along with the disk, if you know what I mean. Actually, our hosts database is set up like this already, except there isn't one alias for each disk, but one per disk cabinet and/or logical group of volumes. This already works if the_server_for_disk1 and the_server_for_disk2 point to different hosts, and there are no other DLEs for that host, of course, but the idea is that they *might* be different aliases for the same host at a certain point in time. - Toralf
Re: Move disk without loosing backup history?
On Thu, Aug 28, 2008 at 7:48 AM, Gene Heskett [EMAIL PROTECTED] wrote: The tar folks at gnu do not consider that a bug, but as a part of the security. To be fair, the tar developers did fix this -- in 1.21, IIRC. As to the original question, no, I don't think that there is any way to pretend that one host/disk is the same as another. When we have a more expressive catalog, it might be interesting to have some kind of redirect that amrecover could follow when browsing the history of a DLE -- similar to Subversion's copy-from. Dustin -- Storage Software Engineer http://www.zmanda.com
Re: Move disk without loosing backup history?
On Thursday 28 August 2008, Dustin J. Mitchell wrote: On Thu, Aug 28, 2008 at 7:48 AM, Gene Heskett [EMAIL PROTECTED] wrote: The tar folks at gnu do not consider that a bug, but as a part of the security. To be fair, the tar developers did fix this -- in 1.21, IIRC. Hrumph... Bleeding edge, and currently bleeding users over the ssh thingy, Fedora is still stuck at 1.17. As to the original question, no, I don't think that there is any way to pretend that one host/disk is the same as another. When we have a more expressive catalog, it might be interesting to have some kind of redirect that amrecover could follow when browsing the history of a DLE -- similar to Subversion's copy-from. Dustin Someone did do a script about a year ago when that bit me that could globally fix the database, but I've forgotten its name now. And you still needed to be pretty savvy to use it. Maybe I wasn't the only one chewing on their attitudes about that item? IMO, either LANANA or tar had to give, having a device number changed just cuz you rebooted to a newer kernel was and is a PITA. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Hideously disfigured by an ancient Indian curse? WE CAN HELP! Call (511) 338-0959 for an immediate appointment.
Re: Move disk without loosing backup history?
On Thursday 28 August 2008, Toralf Lund wrote: Gene Heskett wrote: On Thursday 28 August 2008, Toralf Lund wrote: I've just moved a disk from one server to another without really changing anything with respect to how the clients see it; logically, the disk still represents exactly the same volume on the network. [... ] Unforch, what I'd call a bug in tar will cause it to be treated as a new device. Part of tar's detection code makes the device's assigned number part of the new/old decision. So it will be subjected to a full level 0 backup as a newly discovered disk. This is not really a problem. But I don't think I follow you. Perhaps I wasn't clear enough in my original post; the disk is physically the same as before, it's the *host* that has changed. Correct, and that new host will in all probability, assign a different device major as it discovers the drive during bootup, even if the actual path is identical formatted. To see what it is I'm referring to, do an ls -l /dev/sd* on both machines. Here the major is now 8, but at one point it was being bounced from 253 to 252 depending on whether my USB Key was plugged in! I'd really like the DLE in question to list the actual host it's connected to, and not some client that mounts the volume, so as to avoid sending the same data twice across the network. But if I change the DLE just like that, Amanda will think I'm backing up a new disk (won't it?), so I'll get two separate indexes for what's exactly the same disk, and if I want to recover a really old file, I need to remember to switch to the old index/hostname. Which is something I'd rather avoid. I'm mainly talking about an archival config without tape reuse, by the way. And yes, I do keep amanda indexes from the beginning of time for those, as the way I see it, without these, the tapes would be pretty much useless, since nobody would remember what was supposed to be on them... - Toralf If you can afford to purchase and store the tapes. Here, I need mainly disaster recovery (like when the nvidia binary blob decides to wipe the boot drives LSN0, something that has never happened when running an ati card and the radeon driver, but it took it only 12 hours the last time to trash / so bad it was a hour long hand exec of e2fsck to fix it so I could boot again), or keeping track of stuff when I update the distro. I won't restart amanda after such an update until I have recovered all my pix and those parts of /etc, /home and /root required to keep my bank account accessible, that sort of thing. No 'customer data' to guard as I'm the only customer. :) -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The number of feet in a yard is directly proportional to the success of the barbecue.
