Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #261763
| From | Glenn <ve9gj@napan.com> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: Amanda (was: sata driver compataility Q) |
| Date | 2023-09-19 19:00 +0200 |
| Message-ID | <HfMeR-a5ey-1@gated-at.bofh.it> (permalink) |
| References | (8 earlier) <Hfb5D-9I23-3@gated-at.bofh.it> <HdWil-8Xna-7@gated-at.bofh.it> <HfxSx-9W3f-3@gated-at.bofh.it> <HfIuB-a2Ti-3@gated-at.bofh.it> <HfKG5-a4rJ-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
My all time fav for file level backups is BackupPC. De-duplicates files in the compressed pool. Glenn On September 19, 2023 12:18:36 p.m. ADT, gene heskett <gheskett@shentel.net> wrote: >On 9/19/23 08:59, Stefan Monnier wrote: >>> Compared to the setup required for amanda, that sounds very inviting. Amanda >>> has a very steep learning curve just because it is so versatile I'm still >>> waiting on stuff, so no more actual progress. >> >> I used Amanda many years ago and was quite pleased with it, but I must >> say I'm having a hard time imagining it in my current world where tapes >> don't make much sense for backups. >> >Thats where vtapes come in, A vtape is nothing more than a directory on the backup medium, which for me was a BIG hard drive with in my case, 60 suddirs, used as tapes. Each contained individual files identified as to backup level which was a way ti differentiate a full copy, or what had ben changed since the last full, or what had been changed since the last level 1, wash rinse repeat for ever deeper levels. And with or w/o compression. Executables generally aren't worth the time to compress. Ditto for a dir full if pictures or pdf's. They are not very compressible. In the days of tapes, a buffer drive was used to build up each entry as a big file that was then copied to the tape w/o any shoe-shining of the tapedrive, saveibg the huge wear and tear of the tape if it had to stop and wait for data from the compressor. Then back uo a few feet, back forward to begin a fresh write at the end of the previous track. But since spinning rust is random access, amd so is the vtape, I don't think the anti-shoeshine has much if any advantage whrn using vtapes. With some filesystems it might reduce fragmentation but that was never a problem with ext4. I ran with that buffer drive for about 17 yeas, starting out with a 4 tape seagate dds4 tape drive but it was by far, the least dependable thing in that whole chain. I was then backing up 3 cnc machines and this ones predecessor, but the drive needed a months vacation in Oklahoma city about 2x a year for a new head drum that seagate would not sell me, a CET with extensive experience replacing even smaller, more precise and damn sure more expensive at $3500 a copy dvc-pro broadcast vcr heads. So I tried vtapes, first on a 220G drive but soon opted for a bigger one as they became available, and had just graduated to a pair of seagates first 2T's, both of which just disapeared off the sata buss in the middle of the night. the main drive for this machine and the amanda drive. They were about 2 weeks old. So I rebuilt this machine using a 500G Samsung SSD. I was out of the amanda business and lost everything with those 2 failures, whih upset me so much I never tried to warranty them. I was done with spinning rust. > >Some of the loss was the only pix of my first wife who had a stroke and died in '68 at 34. Left me with 3 children to raise, but the big C and a bottle of scotch has since eliminated them. And my personal email archive that went back to '98 when I built my first linux machine using a 400 mhz k6 cpu. Put RedHat 5.0 on it. And I was in hog heaven, I never owned a windows machine until I needed one for the road after I retired in 2002 and became a consultant, going around to other tv stations putting out engineering fires created by wannabe engineers. The windows xp on it lasted about 2 weeks that it took me to find out windows xp had no drivers for the radio in it, but mandrake did. > >Amanda keeps a database, so if something gets erased you need later, it could be recovered as long as in my case 60 days later before the vtape has been reused. > >One of the things my wrapper did was append that database to the end of that vtape when amanda was finished from its nightly run, thereby making it possible to do a bare metal recovery to the state that existed during the run. Without that, you lost the most recent run because the database you backed up was yesterdays. > >So AFAIAC, amanda was the king. Then amanda was handed over to Zmanda, who eventually went bust and sold it to betsol, who has done zip for it in several years. Community support from other users is all thats left. >Not the end of it of course, but somebody who actually cares needs to fork it and become its new leader. 95% of the work on amanda has been driven by changes in tar over the last decade+. > >> What are the use cases where Amanda still beats the pants down of >> competitors like Borg or Bup? > >I know nothing about either of those. This thread ought to have input from their users so people can make more informed decisions as to which is best for their situation. >> >> >> Stefan >Take care & stay well, Stefan, and other readers. >> >> . > >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, 1940) >If we desire respect for the law, we must first make the law respectable. > - Louis D. Brandeis >Genes Web page <http://geneslinuxbox.net:6309/> >
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Crosshairs in gimp 2.10.22 in Debian 11.7. peter@easthope.ca - 2023-08-12 04:00 +0200
Re: Crosshairs in gimp 2.10.22 in Debian 11.7. Dan Ritter <dsr@randomstring.org> - 2023-08-12 13:10 +0200
Re: Crosshairs in gimp 2.10.22 in Debian 11.7. peter@easthope.ca - 2023-08-12 15:50 +0200
Re: random number generator missing after upgrade Björn Persson <Bjorn@xn--rombobjrn-67a.se> - 2023-08-14 11:30 +0200
Re: random number generator missing after upgrade David Wright <deblis@lionunicorn.co.uk> - 2023-08-14 15:30 +0200
Re: random number generator missing after upgrade Björn Persson <Bjorn@xn--rombobjrn-67a.se> - 2023-08-14 21:00 +0200
Re: random number generator missing after upgrade davidson <davidson@freevolt.org> - 2023-08-14 22:30 +0200
Re: random number generator missing after upgrade Björn Persson <Bjorn@xn--rombobjrn-67a.se> - 2023-08-15 07:50 +0200
Re: upgrade to bookworm broke phpmyadmin Rick Macdonald <rickmacd@shaw.ca> - 2023-08-24 05:30 +0200
Re: upgrade to bookworm broke phpmyadmin Stefan Monnier <monnier@iro.umontreal.ca> - 2023-08-24 16:00 +0200
Re: upgrade to bookworm broke phpmyadmin Rick Macdonald <rickmacd@shaw.ca> - 2023-08-24 23:40 +0200
Re: Please verify Gnome and KDE wiki articles for correctness Jeffrey Walton <noloader@gmail.com> - 2023-08-26 16:30 +0200
Re: Please verify Gnome and KDE wiki articles for correctness <tomas@tuxteam.de> - 2023-08-26 16:50 +0200
Re: raid10 access problem gene heskett <gheskett@shentel.net> - 2023-09-07 19:10 +0200
Re: raid10 access problem gene heskett <gheskett@shentel.net> - 2023-09-07 21:10 +0200
Re: raid10 access problem gene heskett <gheskett@shentel.net> - 2023-09-07 21:10 +0200
Re: Debian, Git server, Nginx, Fcgiwrap, and git push can not create remote object directory David Mehler <dave.mehler@gmail.com> - 2023-09-10 03:30 +0200
Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-10 18:50 +0200
Re: usrmerge on root NFS will not be run automatically Javier Barroso <javibarroso@gmail.com> - 2023-09-11 17:30 +0200
Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-14 16:30 +0200
Re: usrmerge on root NFS will not be run automatically Dan Ritter <dsr@randomstring.org> - 2023-09-14 17:20 +0200
Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-14 18:10 +0200
Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-14 20:30 +0200
Re: usrmerge on root NFS will not be run automatically Stefan Monnier <monnier@iro.umontreal.ca> - 2023-09-14 23:00 +0200
Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-15 14:00 +0200
Re: usrmerge on root NFS will not be run automatically Stefan Monnier <monnier@iro.umontreal.ca> - 2023-09-15 15:30 +0200
Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-14 22:20 +0200
Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-10-03 13:50 +0200
Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-15 14:00 +0200
Re: usrmerge on root NFS will not be run automatically Andy Smith <andy@strugglers.net> - 2023-09-15 20:00 +0200
Re: usrmerge on root NFS will not be run automatically Marco <lists@homerow.info> - 2023-09-15 23:40 +0200
Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-15 23:40 +0200
Re: sata driver compataility Q Andy Smith <andy@strugglers.net> - 2023-09-16 00:00 +0200
Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-16 01:30 +0200
Re: sata driver compataility Q songbird <songbird@anthive.com> - 2023-09-16 12:10 +0200
Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-16 13:50 +0200
Re: sata driver compataility Q songbird <songbird@anthive.com> - 2023-09-16 14:10 +0200
Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-15 23:50 +0200
Re: sata driver compataility Q gene heskett <gheskett@shentel.net> - 2023-09-19 03:40 +0200
Amanda (was: sata driver compataility Q) Stefan Monnier <monnier@iro.umontreal.ca> - 2023-09-19 15:00 +0200
Re: Amanda (was: sata driver compataility Q) gene heskett <gheskett@shentel.net> - 2023-09-19 17:20 +0200
Re: Amanda (was: sata driver compataility Q) Glenn <ve9gj@napan.com> - 2023-09-19 19:00 +0200
Re: PATH revisited: one PATH to "rule the [Debian] World" Greg Wooledge <greg@wooledge.org> - 2023-09-24 19:30 +0200
When a random string is not random (was Re: PATH revisited: one PATH to "rule the [Debian] World") Max Nikulin <manikulin@gmail.com> - 2023-09-25 05:20 +0200
Re: PATH revisited: one PATH to "rule the [Debian] World" Michael Kjörling <2695bd53d63c@ewoof.net> - 2023-09-24 21:50 +0200
Re: PATH revisited: one PATH to "rule the [Debian] World" Greg Wooledge <greg@wooledge.org> - 2023-09-24 22:00 +0200
Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-24 22:50 +0200
Re: PATH revisited: one PATH to "rule the [Debian] World" Michael Kjörling <2695bd53d63c@ewoof.net> - 2023-09-24 23:00 +0200
Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-24 23:30 +0200
Message IDs, was Re: PATH revisited: one PATH to "rule the [Debian] World" David Wright <deblis@lionunicorn.co.uk> - 2023-09-25 05:20 +0200
Re: Message IDs, was Re: PATH revisited: one PATH to "rule the [Debian] World" Dan Ritter <dsr@randomstring.org> - 2023-09-25 13:10 +0200
csiph-web