Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #179258 > unrolled thread

A bit OT: Amanda Restore

Back to article view | Back to linux.debian.user

Contents

  A bit OT: Amanda Restore Mark Fletcher <mark27q1@gmail.com> - 2017-03-24 17:00 +0100
    Re: A bit OT: Amanda Restore Gene Heskett <gheskett@shentel.net> - 2017-03-24 17:50 +0100
      Re: A bit OT: Amanda Restore Mark Fletcher <mark27q1@gmail.com> - 2017-03-25 16:50 +0100
        Re: A bit OT: Amanda Restore Gene Heskett <gheskett@shentel.net> - 2017-03-25 18:40 +0100
    Re: A bit OT: Amanda Restore Dan Ritter <dsr@randomstring.org> - 2017-03-24 18:40 +0100
      Re: A bit OT: Amanda Restore Mark Fletcher <mark27q1@gmail.com> - 2017-03-25 17:00 +0100

#179258 — A bit OT: Amanda Restore

Hello

A while back I installed Amanda for backups. I have a pretty simple 
setup at the moment which I may expand later. At the moment only one 
machine, running Jessie, is backed up by Amanda.

My main PC is both the Amanda server and the machine Amanda is backing 
up. Recently I started to think about what would happen if I suffered a 
catastrophic failure on this machine. Like if one of its SSDs died a 
sudden death.

I have read up on amrecover but both the documentation and what I have 
read in forums online seem to assume that in a recovery situation the 
Amanda server will be intact. How then is one supposed to protect the 
Amanda server? And in my case, what is the best way to make sure my 
Amanda backups are actually usable for restore in a recovery situation? 

The backup "tapes" are virtual tapes on large-capacity disks in an 
external USB3 drive cage. The recovery scenario is my PC takes a 
nosedive but the contents of the external drive cage are fine. For 
example, failure of one internal SSD in the PC containing most of the 
operating system, /home etc.

Perhaps a bit more background in case needed to be clear: I am not 
bothering to back up the system software that I can replace by 
reinstalling Jessie. I am only backing up /etc, /opt (where I have a SVN 
repository, a mysql database, a big bunch of videos, and the hard disks 
of 2 Windows VMs) and a few other places, including of course /home. My 
backup script shuts down my SVN server and my mysql database, and either 
includes or excludes the disks for my VMs depending on whether they are 
running, then kicks off Amanda. So /etc/amanda/disklist gets built every 
time from a template and based on the circumstances the script finds on 
each run. I note looking in /etc/amanda/ that disklist and tapelist are 
both updated every time, disklist by my script and tapelist presumably 
by Amanda.

I'd assume that if I suffered a disk failure, replaced the disk, 
re-installed Jessie and tried to use Amanda to restore my backups of my 
stuff, I'd be hosed right now because my current /etc/amanda and its 
subdirectories would be gone. Is this correct? Amanda would not be able 
to recover in this situation, right?

If so, I need to back those up some other way. And I need to do so every 
day, because Amanda will update the tapelist file every day, and I'd 
assume if I don't have the latest tapelist file it's not going to be 
able to restore my backups??? Is that correct?

What is the _right_ way to do this? And, if I were using Amanda as its 
creators obviously intended and backing up multiple machines, what would 
the recommended way to back up the Amanda server itself (ie its 
configuration and current state) be?

I plan in a few days to boot this machine from a live Jessie ISO, and 
run a "restore" to a spare large disk I have lying around, to check I 
understand how to restore after a disaster. Preparing myself mentally 
for that has led me to the realisation I am nowhere near ready in my 
understanding...

I know there are some long-standing users of Amanda on here so I'm 
hoping someone can help me figure out what I am missing...

Thanks in advance

Mark

[toc] | [next] | [standalone]

#179261

On Friday 24 March 2017 11:51:27 Mark Fletcher wrote:

> Hello
>
> A while back I installed Amanda for backups. I have a pretty simple
> setup at the moment which I may expand later. At the moment only one
> machine, running Jessie, is backed up by Amanda.
>
> My main PC is both the Amanda server and the machine Amanda is backing
> up. Recently I started to think about what would happen if I suffered
> a catastrophic failure on this machine. Like if one of its SSDs died a
> sudden death.
>
> I have read up on amrecover but both the documentation and what I have
> read in forums online seem to assume that in a recovery situation the
> Amanda server will be intact. How then is one supposed to protect the
> Amanda server? And in my case, what is the best way to make sure my
> Amanda backups are actually usable for restore in a recovery
> situation?
>
> The backup "tapes" are virtual tapes on large-capacity disks in an
> external USB3 drive cage. The recovery scenario is my PC takes a
> nosedive but the contents of the external drive cage are fine. For
> example, failure of one internal SSD in the PC containing most of the
> operating system, /home etc.
>
> Perhaps a bit more background in case needed to be clear: I am not
> bothering to back up the system software that I can replace by
> reinstalling Jessie. I am only backing up /etc, /opt (where I have a
> SVN repository, a mysql database, a big bunch of videos, and the hard
> disks of 2 Windows VMs) and a few other places, including of course
> /home. My backup script shuts down my SVN server and my mysql
> database, and either includes or excludes the disks for my VMs
> depending on whether they are running, then kicks off Amanda. So
> /etc/amanda/disklist gets built every time from a template and based
> on the circumstances the script finds on each run. I note looking in
> /etc/amanda/ that disklist and tapelist are both updated every time,
> disklist by my script and tapelist presumably by Amanda.
>
> I'd assume that if I suffered a disk failure, replaced the disk,
> re-installed Jessie and tried to use Amanda to restore my backups of
> my stuff, I'd be hosed right now because my current /etc/amanda and
> its subdirectories would be gone. Is this correct? Amanda would not be
> able to recover in this situation, right?
>
Correct. This is why I use a different disk for amanda backup files, and 
I wrote a script to wrap the amanda run so that when amanda is done, 
this script appends the complete amanda configuration, and its database, 
to the end of that backup. This has the added advantage of being able to 
do a recovery to the state of the last backup run, instead of the day 
before because the on disk amanda stuff, as recorded in the backup, is a 
run old. Its hand work to do an install on a new system disk, but then I 
can unpack that stuff from the "amanda" disk to install amanda's config 
and database. From that point its amrecover run time and when done I 
have a system exactly the same a it existed at 01:40 or so in the 
morning.

> If so, I need to back those up some other way. And I need to do so
> every day, because Amanda will update the tapelist file every day, and
> I'd assume if I don't have the latest tapelist file it's not going to
> be able to restore my backups??? Is that correct?

Thats the job of the separate disk, saving that stuff.
>
> What is the _right_ way to do this? And, if I were using Amanda as its
> creators obviously intended and backing up multiple machines, what
> would the recommended way to back up the Amanda server itself (ie its
> configuration and current state) be?

Poke around on my site in the sig and get the GenesAmandaHelper stuff, 
install it in a subdir of the same name, and change your cron job to run 
backup.sh that you will find in this subdir when its unpacked. You may 
have to edit something, and play with the onwer:group settings etc to 
get it to run, possibly even a configuration change but the idea is 
there.

> I plan in a few days to boot this machine from a live Jessie ISO, and
> run a "restore" to a spare large disk I have lying around, to check I
> understand how to restore after a disaster. Preparing myself mentally
> for that has led me to the realisation I am nowhere near ready in my
> understanding...

This will be a good learning experience in that regard.

I am disgustingly sold on amanda being a better idea. The original theory 
was that with the limited size of tapes back in the dark ages, amanda 
played mix & match with the backup incrementals to try to achieve the 
same tape usage every run, ideally filling each tape to maximum 
capacity, and that worked well enough to surprise me. However, the 
development of vtapes, which are nothing more than directories and tgz 
files per disklist entry in those directories, converts amanda's 
recovery operations into random access as opposed to reading the whole 
tape to find one 273 byte file, so recoveries are much less painfull.

Throw in that I have found over the years that hard drives, since made in 
macroscopic quantities compared to tapes and tape drives, are easily 20 
to 1000x more dependable than the tapes I could afford in quantities for 
a 30 day recovery, thats all gravy.

My current /amandatapes drive had 25 reallocated sectors the first time I 
checked it with smartctl at perhaps 5k hours, I downloaded and installed 
fresh firmware from the seagate site, didn't lose a byte and gained 
drive data r/w speed and earlier this week that same still reports that 
same 25 re-allocated sectors after something north of 62,000 spinning 
hours. No tape drive regardless of the size of the pile of sheckles you 
paid for it, can realisticly do 10% of that service life. In my 
experience, they had an urge to spend about 6 weeks in Oklahoma City 
being rebuilt over the Thanksgiving -> New years period.

That faint thumping sound?  Me, knocking on my skull as a good substitute 
for wood. ;-) IWFM. YMMV.

> I know there are some long-standing users of Amanda on here so I'm
> hoping someone can help me figure out what I am missing...

Does since 1999 count? ;-)

> Thanks in advance
>
> Mark


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#179309

On Fri, Mar 24, 2017 at 12:49:19PM -0400, Gene Heskett wrote:
> On Friday 24 March 2017 11:51:27 Mark Fletcher wrote:
> 
> > I'd assume that if I suffered a disk failure, replaced the disk,
> > re-installed Jessie and tried to use Amanda to restore my backups of
> > my stuff, I'd be hosed right now because my current /etc/amanda and
> > its subdirectories would be gone. Is this correct? Amanda would not be
> > able to recover in this situation, right?
> >
> Correct. This is why I use a different disk for amanda backup files, and 
> I wrote a script to wrap the amanda run so that when amanda is done, 
> this script appends the complete amanda configuration, and its database, 
> to the end of that backup. This has the added advantage of being able to 
> do a recovery to the state of the last backup run, instead of the day 
> before because the on disk amanda stuff, as recorded in the backup, is a 
> run old. Its hand work to do an install on a new system disk, but then I 
> can unpack that stuff from the "amanda" disk to install amanda's config 
> and database. From that point its amrecover run time and when done I 
> have a system exactly the same a it existed at 01:40 or so in the 
> morning.
> 

Right makes sense. But Hmmm.. "...and database...". Database? would that 
be /var/lib/amanda, or something else?

So I'm concerned with /etc/amanda and below, and /var/lib/amanda and 
below, right?

> > What is the _right_ way to do this? And, if I were using Amanda as its
> > creators obviously intended and backing up multiple machines, what
> > would the recommended way to back up the Amanda server itself (ie its
> > configuration and current state) be?
> 
> Poke around on my site in the sig and get the GenesAmandaHelper stuff, 
> install it in a subdir of the same name, and change your cron job to run 
> backup.sh that you will find in this subdir when its unpacked. You may 
> have to edit something, and play with the onwer:group settings etc to 
> get it to run, possibly even a configuration change but the idea is 
> there.
> 

Nice one, thanks -- I will check this out!

> > I know there are some long-standing users of Amanda on here so I'm
> > hoping someone can help me figure out what I am missing...
> 
> Does since 1999 count? ;-)
> 
It does indeed -- in fact it was you, Gene, that I was hoping would 
respond to this question! :) I almost mailed you directly, since the 
question was a touch OT for the list, but thought that might be a bit 
presumptious.

Thanks for your help!

Mark

[toc] | [prev] | [next] | [standalone]

#179313

On Saturday 25 March 2017 11:43:51 Mark Fletcher wrote:

> On Fri, Mar 24, 2017 at 12:49:19PM -0400, Gene Heskett wrote:
> > On Friday 24 March 2017 11:51:27 Mark Fletcher wrote:
> > > I'd assume that if I suffered a disk failure, replaced the disk,
> > > re-installed Jessie and tried to use Amanda to restore my backups
> > > of my stuff, I'd be hosed right now because my current /etc/amanda
> > > and its subdirectories would be gone. Is this correct? Amanda
> > > would not be able to recover in this situation, right?
> >
> > Correct. This is why I use a different disk for amanda backup files,
> > and I wrote a script to wrap the amanda run so that when amanda is
> > done, this script appends the complete amanda configuration, and its
> > database, to the end of that backup. This has the added advantage of
> > being able to do a recovery to the state of the last backup run,
> > instead of the day before because the on disk amanda stuff, as
> > recorded in the backup, is a run old. Its hand work to do an install
> > on a new system disk, but then I can unpack that stuff from the
> > "amanda" disk to install amanda's config and database. From that
> > point its amrecover run time and when done I have a system exactly
> > the same a it existed at 01:40 or so in the morning.
>
> Right makes sense. But Hmmm.. "...and database...". Database? would
> that be /var/lib/amanda, or something else?
>
> So I'm concerned with /etc/amanda and below, and /var/lib/amanda and
> below, right?

In my case I didn't change the build target since it was /usr/local, so 
my config is /usr/local/etc/amanda, and the database 
is /usr/local/var/amanda.

/etc/amandahosts, with my install only has the security id thing, called 
amandahosts, although its linked as .amandahosts to several other 
locations.

The clients seem to want it as /etc/amandahosts though.

Currently running 3.3.7p1 on this, the server for several years, and 
whatever the distro supplies on the clients. I did try the latest 3.4.3 
about 2 weeks back, but so many config changes ruined any chance of 
doing a backup without hours of wading thru new config things, so I took 
the path of least resistance and went back to 3.3.7p1. I keep 
a /home/amanda tree just for building it from the tarball.  Had to build 
it from scratch.  Apparently I had done a make clean in that src tree at 
some time in the now dim past..

That difference in paths tends to separate the noise as those are not 
popular paths.

> > > What is the _right_ way to do this? And, if I were using Amanda as
> > > its creators obviously intended and backing up multiple machines,
> > > what would the recommended way to back up the Amanda server itself
> > > (ie its configuration and current state) be?
> >
> > Poke around on my site in the sig and get the GenesAmandaHelper
> > stuff, install it in a subdir of the same name, and change your cron
> > job to run backup.sh that you will find in this subdir when its
> > unpacked. You may have to edit something, and play with the
> > onwer:group settings etc to get it to run, possibly even a
> > configuration change but the idea is there.
>
> Nice one, thanks -- I will check this out!
>
> > > I know there are some long-standing users of Amanda on here so I'm
> > > hoping someone can help me figure out what I am missing...
> >
> > Does since 1999 count? ;-)
>
> It does indeed -- in fact it was you, Gene, that I was hoping would
> respond to this question! :) I almost mailed you directly, since the
> question was a touch OT for the list, but thought that might be a bit
> presumptious.
>
> Thanks for your help!
>
> Mark

Decent, save your butt backups shouldn't be off-topic for any distro's 
support lists. Presently I have 4 machines running wheezy in 32 bit even 
with 64 bit cpu's, mainly because up until recently, none of the 64 bit 
installs were antwhere near fast enough to run linuxcnc.

To wander farther off-topic;

But I am down to only one machine still running software stepping and 
intend to put a mesa 5i25 card in it to take over the step generation 
for the motors, which should allow it to run 175% faster, and if I can 
find a different psu still with a 5 volt output, but up around 40 volts 
& 10 amps for the motors, it will run 300% faster when cutting air. But 
when doing EDM on it, the feed rate is maybe .010" a minute, and 
recently thats all I have used it for. EDM can be used like a hacksaw 
blade, but thinner, and zero burrs on either side of the cut.

I do have one machine, running the raspbian jessie 64 bit build on a 
raspberry pi 3b.  That, with a mesa 7i90 interface card, is loafing at 
maybe 5% cpu being used by linuxcnc. Very efficient except for 
electrical spikes getting into the interface, its a 3.3 volt interface 
and very easily destroyed by all the noise being generated by all the 
switchmode devices it takes to run motors efficiently. 

All grounding MUST be star config to a single bolt, with the grounds 
going here and there well insulated until they get to where they are 
going. They can't touch anything else getting there because thats a 
ground loop, radiating or picking up the noise. I have about 20 of those 
clamp on ferrite chokes to block and slow it, and nearly have it under 
control. But not quite.

ATM I am pokeing around in a 2x2x1" block of steel because I just _know_ 
there is a taperlock hub hiding in it.  But thats off topic, other than 
the computer driving that witching stick, a small lathe known 
disaffectionately as TLM for "The Little Monster", is running debian 
wheezy.

I have many hobbies in my so-called golden years. Too many perhaps. ;-)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#179265

On Sat, Mar 25, 2017 at 12:51:27AM +0900, Mark Fletcher wrote:
> A while back I installed Amanda for backups. I have a pretty simple 
> setup at the moment which I may expand later. At the moment only one 
> machine, running Jessie, is backed up by Amanda.
> 
> My main PC is both the Amanda server and the machine Amanda is backing 
> up. Recently I started to think about what would happen if I suffered a 
> catastrophic failure on this machine. Like if one of its SSDs died a 
> sudden death.

I'm going to suggest that amanda is not the best solution for
you in this situation.

> The backup "tapes" are virtual tapes on large-capacity disks in an 
> external USB3 drive cage. The recovery scenario is my PC takes a 
> nosedive but the contents of the external drive cage are fine. For 
> example, failure of one internal SSD in the PC containing most of the 
> operating system, /home etc.

I'll take a wild guess and suggest that your SSD is 1 TB or
smaller.

Let's take a cost-effective 2TB spinning disk and partition it in 2
equal-sized chunks. On odd-numbered days, copy your entire SSD
to partition 1 via dd. On weekends, copy your entire SSD to
partition 2 via dd. Make sure you have a GRUB boot CD or USB
stick available.

Now you have an image available that's no more than 2 days old,
and another which is no more than 7 days old. You should be able
to recover a single file that you accidentally deleted by simply
mounting the filesystem and copying it over. You can recover
from a whole-SSD failure by booting with GRUB and then picking
the right partition to boot from; when you have time, you can go
buy a new SSD.

For backing up other data stores you have in the system, amanda
might well be the right choice. But for bare-metal recovery
coupled with the more frequent oh-no-I-deleted-what? scenario,
this will make your life much happier.

-dsr-

[toc] | [prev] | [next] | [standalone]

#179310

On Fri, Mar 24, 2017 at 01:39:12PM -0400, Dan Ritter wrote:
> I'm going to suggest that amanda is not the best solution for
> you in this situation.

I was actually starting to think the same thing myself as I was writing 
my original mail last night, but I do intend to expand my setup to 
include more of my network later, at which point this setup will start 
to make more sense.

> I'll take a wild guess and suggest that your SSD is 1 TB or
> smaller.

Two 960GB SSDs, yes. One mounted on / with a small handful of partitions 
and the other one big partition mounted on /opt.

> 
> Let's take a cost-effective 2TB spinning disk and partition it in 2
> equal-sized chunks. On odd-numbered days, copy your entire SSD
> to partition 1 via dd. On weekends, copy your entire SSD to
> partition 2 via dd. Make sure you have a GRUB boot CD or USB
> stick available.
> 
> Now you have an image available that's no more than 2 days old,
> and another which is no more than 7 days old. You should be able
> to recover a single file that you accidentally deleted by simply
> mounting the filesystem and copying it over. You can recover
> from a whole-SSD failure by booting with GRUB and then picking
> the right partition to boot from; when you have time, you can go
> buy a new SSD.

Makes sense, until I get to the point of being more organised about 
backing up more of my network.

Thanks for your advice

Mark

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web