On Friday 25 September 2020 14:25:16 RĂ¼diger Kessel wrote: > Dear Gene, > > you mentioned that you use a dumpcycle of 58 days with incremental > backups in between. > > I use a bit longer dumpcycle and I have problems when I use the > amrecover tool. > > The problem is connected with the fact that amrecover consumes a lot > of ports and will eventually run out of some internal buffer space. > This only happens if the dumpcycle is larger than about 40. > > I can restore the disks from backup reliably by using amfetchdump, but > with amrecover it depends. > > Have you seen this problem before? > > Best regards > > RĂ¼diger Kessel > No I haven't. OTOH, I have not had occasion to restore since I had a motherboard fire, destroying one of the usb ports, and put a new Asus X370 mobo, a 6 core 3.7GHz I5, and 32 GB of dram behind that same set of drives and rebooted. My thoughts are that with that much memory to play with, it probably will not have a problem. My backups are running, doing 5 machines with the compressible stuff being fed to gzip -best, in usually under an hour for nominally 20 to 30GB written to a 2TB drive.Are you able to monitor memory useage while amrecover is running, with something like htop? Might be educational for both of us.
> Am Fr., 25. Sept. 2020 um 16:24 Uhr schrieb Gene Heskett < > > [email protected]>: > > On Friday 25 September 2020 09:19:58 Dave Sherohman wrote: > > > Howdy, all! > > > > > > We've recently had some problems at work with our backup provider, > > > so my boss has come to me and requested a recommendation for > > > bringing backups in-house. I've previously adminned a small > > > amanda installation back in 2000-2006 and I quite liked the system > > > and how it works, so that was my first thought. > > > > > > I've done some general web searches and it looks like the > > > situation today isn't as good as it was a decade and a half ago - > > > not a lot of active development, limited support for Windows > > > clients, etc. But, on the other hand, amanda was already a very > > > mature system back then, so I don't know that a lot of ongoing > > > development would still be needed. > > > > > > So let's see what the current users have to say. Is a new amanda > > > installation still a sane choice in 2020? > > > > > > My use case is that I'll be backing up somewhere in the > > > neighborhood of 75ish servers, a mix of physical and (mostly) > > > virtual machines, and a mix of mostly Linux with some Windows and > > > one or two FreeBSD. Total disk usage is currently in the 35-40 TB > > > range, growing by maybe 1-2 TB per year. Aside from my own > > > positive experiences with amanda, both I and my boss (and most of > > > my coworkers) are very pro-open-source. > > > > > > If amanda isn't a reasonable choice for that scenario, what would > > > be a better option? > > > > > > And what kind of hardware specs should I be looking at? Is tape > > > still king, or is everyone backing up to hard drives now? > > > > I've been useing hard drives with amanda for over a decade now, I'd > > estimate they are 100x more dependable than tape, as I've had zero > > hd failures, and dozens of tape failures and tape drives that > > absolutely had to spend the holidays in Oklahoma City being rebuilt. > > And some of the HD's had nearly 100k spinning hours on them when > > they got too small. Currently doing 5 machines nightly, with about > > 58 days for vtapes recycle. Whats not to like? Amanda has Just > > Worked here since the later 90's. > > > > 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) > > If we desire respect for the law, we must first make the law > > respectable. - Louis D. Brandeis > > Genes Web page <http://geneslinuxbox.net:6309/gene> 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) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
