Re: Initial disk of amrecover set up incorrectly
>amrecover will in my setup make a completely wrong guess about what disk >to consider at startup in most cases. The example output included below >should illustrate the problem; /usr/freeware/apache is not on the /u >filesystem, and it has a separate disklist entry. Any ideas what is going >on? >... >$CWD '/usr/freeware/apache' is on disk '/u' mounted at '/u'. So where is it mounted? What happens if you run "df -k /usr/freeware/apache"? It's part of the root filesystem; # df -k /usr/freeware/apache Filesystem Type kbytes use avail %use Mounted on /dev/root xfs 16727944 4923500 1180 30 / From Amanda's viewpoint it's a separate entity, though, like I said; it has it's own DLE backed up using GNUTAR. What is the output for "mount" (with no args it lists your mount table). # mount /dev/root on / type xfs (rw,raw=/dev/rroot) /hw on /hw type hwgfs (rw) /proc on /proc type proc (rw) /dev/fd on /dev/fd type fd (rw) /dev/xlv/stripedvol2 on /scanner type xfs (0) /dev/dsk/dks2d11s7 on /dumps type xfs (0) /dev/dsk/dks2d14s7 on /u2 type xfs (0) /dev/xlv/stripedvol3 on /scanner2 type xfs (0) /dev/dsk/dks0d5s7 on /u type xfs (quota) /dev/xlv/stripedvol1 on /scanner3 type xfs (0) linuxdoc:/usr/share/doc on /usr/doc-linux type nfs (vers=2,rw,intr,bg,dev=18) raid1:/imgproc on /imgproc type nfs (vers=3,rw,intr,bg,dev=140002) imgproc:/imgproc2 on /imgproc2 type nfs (vers=3,rw,intr,bg,dev=140001) imgproc:/imgproc3 on /imgproc3 type nfs (vers=3,rw,intr,bg,dev=140003) raid2:/scanner4 on /scanner4 type nfs (vers=2,rw,intr,bg,dev=180001) localhost:/var/www on /var/www-server type nfs (vers=3,rw,intr,bg,dev=140004) What's in /tmp/amanda/amrecover*.debug? There should be some lines referring to "guess_disk". I don't see any. The complete contents (which don't make a lot of sense to me) is included below. The following few lines from amindexd.*.debug may explain a lot, though: OISD sr/freeware/apache f /dumps/amanda/ks/index/fileserv/_u/20030102_0 < 500 "sr/freeware/apache" is an invalid directory --- File amrecover.20030106084800.debug: amrecover: debug 1 pid 27890309 ruid 0 euid 0 start time Mon Jan 6 08:48:00 2003 amrecover: stream_client: connected to 193.214.130.4.10082 amrecover: stream_client: our side is 0.0.0.0.821 add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/." add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/.Trash-hhe/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/.Trash-jfo/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/.Trash-paal/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/.Trash-root/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/.amanda.excludes" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/.nautilus-metafile.xml" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/CVS/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/KENmaster/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/dist/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/ent" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/fax/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/ftp/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/laptoptest.aw" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/logo/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/lost+found/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/mail/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/marketing/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/marketing2/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/test/" add_dir_list_item: Adding "2003-01-02" "0" "Tor-3" "/www.kscanners.com.key"
www.ilrehberi.com - FIRMANIZI KAYDEDINIZ
Title: Untitled Document Tüm Dünya Size Bu Sitelerden Ulaþacak www.ilrehberi.com | Firma ekle Bedava Firmanýzý Ekleyin ! Bulunduðunuz Ýl ve Kategori bölümünde Banner Reklamý 60 Milyon TL. Talep www.sectorguide.com | Firma ekle www.tekstilrehberi.com | Firma ekle www.turkhotelsguide.com | Firma ekle www.acentarehberi.com | Firma ekle www.imalatsanayi.com | Firma ekle www.otogar.net | Firma ekle www.mailrehberi.com |Mail Portföyü (5.milyon Adet) Web Siteniz olsun ( 120 milyon TL) Talep Formu Domain + Hosting + Tasarým + Arama Motorlarýna Kayýt + Kontrol Paneli - Sýnýrsýz email. (c) Mega Internet Þti Tel&Fax : 0 222 220 44 91 | [EMAIL PROTECTED]
Re: GNUTAR "include" instead of "exclude"
On Sun, Jan 05, 2003 at 01:02:22PM -0800, Will Lowe wrote:
> > Note carefully that Jon says "like". The "include" keyword does *not*
> > do patterns. You must explicitly list each item to be included.
>
> That's ok, provided I can list directories ... something like this:
>
> ./var/spool/mail
> ./usr/local
> ./etc
> ./var/log/samba
>
> ... and just catch those directories and everything in them. That
> will work, I presume? The manpage says soemthing confusing about not
> allowing more than one '/', but gnutar's -T option seems to support
> that just fine.
Try this patch, amanda will use the pattern without check if it
contains to /.
Jean-Louis
--
Jean-Louis Martineau email: [EMAIL PROTECTED]
Departement IRO, Universite de Montreal
C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529
Montreal, Canada, H3C 3J7Fax: (514) 343-5834
--- /u/martinea/amcore/amanda-2.4.3/client-src/client_util.c2003-01-02
20:05:56.0 -0500
+++ client-src/client_util.c2003-01-05 17:31:36.0 -0500
@@ -193,28 +193,32 @@
return 0;
}
else {
- char *glob;
- char *regex;
- DIR *d;
- struct dirent *entry;
-
- glob = ainc+2;
- regex = glob_to_regex(glob);
- if((d = opendir(device)) == NULL) {
- dbprintf(("%s: Can't open disk '%s']\n",
- debug_prefix(NULL), device));
- if(verbose)
- printf("ERROR [Can't open disk '%s']\n", device);
- return 0;
+ char *incname = ainc+2;
+ if(strchr(incname, '/')) {
+ fprintf(file_include, "./%s\n", incname);
}
else {
- while((entry = readdir(d)) != NULL) {
- if(is_dot_or_dotdot(entry->d_name)) {
- continue;
- }
- if(match(regex, entry->d_name)) {
- fprintf(file_include, "./%s\n", entry->d_name);
- nb_exp++;
+ char *regex;
+ DIR *d;
+ struct dirent *entry;
+
+ regex = glob_to_regex(incname);
+ if((d = opendir(device)) == NULL) {
+ dbprintf(("%s: Can't open disk '%s']\n",
+ debug_prefix(NULL), device));
+ if(verbose)
+ printf("ERROR [Can't open disk '%s']\n", device);
+ return 0;
+ }
+ else {
+ while((entry = readdir(d)) != NULL) {
+ if(is_dot_or_dotdot(entry->d_name)) {
+ continue;
+ }
+ if(match(regex, entry->d_name)) {
+ fprintf(file_include, "./%s\n", entry->d_name);
+ nb_exp++;
+ }
}
}
}
Re: recover oddities on SCO Openserver, solved
>>* The hostname that amanda detects on SCO Openserver does not match the >> hostname that is reported by 'hostname' or 'uname -a'. > >Can you post an example? This might be simple calling the wrong routine >on SCO to get the host name (more OS differences as mentioned above). uname -a SCO_SV cclcsup 3.2 5.0.6 i386 unknown However: /usr/local/sbin/amrecover Daily AMRECOVER Version 2.4.3. Contacting server on cclcsup ... 220 cclcsup AMANDA index server (2.4.3) ready. 200 Access OK Setting restore date to today (2003-01-06) 200 Working date set to 2003-01-06. 200 Config set to Daily. 501 No index records for host: cclcsup.remote-print.com. Invalid? Trying host cclcsup ... 200 Dump host set to cclcsup. Can't determine disk and mount point from $CWD '/home/development/3rdparty_tools/amanda-2.4.3' If I do a 'sethost cclcsup', it works. I am going to try setting up a local DNS, (since we should really have one anyway) and see if that solves the problem. >>* Oddly, when you've navigated to what you want to restore, add it, >> and extract it, it does the extract from the disk level, not the >> directory you were in when you added it. Not a big problem, but >> it caused a wee bit of confusion. > >Huh? Again, can you show an example. > >In general, if you told Amanda to back up disk "/usr" and one of the files >backed up was "/usr/a/b/xxx", then if you start amrecover in directory >"/tmp/restore", the file brought back will be "/tmp/restore/a/b/xxx". >In other words, things backed up only know themselves relative to the >top level being processed (i.e. "a/b/xxx"), and they should come back >relative to whatever directory you do the restore into. Continuing from amrecover above: amrecover> sethost cclcsup 200 Dump host set to cclcsup. amrecover> setdisk /home Scanning /usr/local/amanda/dumps... 200 Disk set to /home. amrecover> ls 2003-01-03 . 2003-01-03 development/ 2003-01-03 todo/ 2003-01-03 users/ amrecover> cd users /home/users amrecover> ls 2003-01-03 . 2003-01-03 andrew-backup/ 2003-01-03 andrew/ amrecover> add andrew Added dir /users/andrew at date 2003-01-03 amrecover> extract Extracting files using tape drive /dev/nrStp0 on host cclcsup. The following tapes are needed: DailySet101 Restoring files into directory /home/development/3rdparty_tools/amanda-2.4.3 Continue [?/Y/n]? Extracting files using tape drive /dev/nrStp0 on host cclcsup. Load tape DailySet101 now Continue [?/Y/n/t]? ./users/andrew/ amrecover> quit 200 Good bye. ls -al drwxr-xr-x 18 1029 203 1024 Jan 6 08:47 . drwxr-xr-x 17 root sys 512 Dec 27 11:52 .. drwxr-xr-x 3 andrew users 512 Jan 6 08:47 users ls -al users total 3 drwxr-xr-x 3 andrew users 512 Jan 6 08:47 . drwxr-xr-x 18 1029 203 1024 Jan 6 08:47 .. drwxr-xr-x 2 root sys 512 Jan 6 08:47 andrew >>* When GNU tar is installed off the skunkware CD, it appears as >> /usr/local/bin/tar. Amanda apparently looks for gtar. > >Not sure what you mean here. If you ran ./configure yourself, it should >have hunted around and found this version of tar (as Jean-Louis said). >If, however, you're running a pre-built version of Amanda, all bets are >off about how the person who put it together set things up. SCO Openserver ships with it's own version of tar: /usr/bin/tar -> /opt/K/SCO/Unix/5.0.6Ga/usr/bin/tar Installing skunkware installs GNU tar as: /usr/local/bin/tar -> /opt/K/SKUNK2000/Tar/1.12/usr/local/bin/tar My guess is that the configure script detected the wrong tar. specifying the location of tar with the --with-gnutar option works, as does making a symlink of: /usr/local/bin/gtar -> /usr/local/bin/tar -Josh
Re: recover oddities on SCO Openserver, solved
On Mon, Jan 06, 2003 at 10:03:02AM -0600, Josh More wrote: > > >>* Oddly, when you've navigated to what you want to restore, add it, > >> and extract it, it does the extract from the disk level, not the > >> directory you were in when you added it. Not a big problem, but > >> it caused a wee bit of confusion. > > > >Huh? Again, can you show an example. > > > >In general, if you told Amanda to back up disk "/usr" and one of the files > >backed up was "/usr/a/b/xxx", then if you start amrecover in directory > >"/tmp/restore", the file brought back will be "/tmp/restore/a/b/xxx". > >In other words, things backed up only know themselves relative to the > >top level being processed (i.e. "a/b/xxx"), and they should come back > >relative to whatever directory you do the restore into. > > /usr/local/sbin/amrecover Daily > AMRECOVER Version 2.4.3. Contacting server on cclcsup ... > 220 cclcsup AMANDA index server (2.4.3) ready. > 200 Access OK > Setting restore date to today (2003-01-06) > 200 Working date set to 2003-01-06. > 200 Config set to Daily. > 501 No index records for host: cclcsup.remote-print.com. Invalid? > Trying host cclcsup ... > 200 Dump host set to cclcsup. > Can't determine disk and mount point from $CWD >'/home/development/3rdparty_tools/amanda-2.4.3' > amrecover> sethost cclcsup > 200 Dump host set to cclcsup. > amrecover> setdisk /home > Scanning /usr/local/amanda/dumps... > 200 Disk set to /home. > amrecover> ls > 2003-01-03 . > 2003-01-03 development/ > 2003-01-03 todo/ > 2003-01-03 users/ > amrecover> cd users > /home/users > amrecover> ls > 2003-01-03 . > 2003-01-03 andrew-backup/ > 2003-01-03 andrew/ > amrecover> add andrew > Added dir /users/andrew at date 2003-01-03 > amrecover> extract > > Extracting files using tape drive /dev/nrStp0 on host cclcsup. > The following tapes are needed: DailySet101 > > Restoring files into directory /home/development/3rdparty_tools/amanda-2.4.3 > Continue [?/Y/n]? > > Extracting files using tape drive /dev/nrStp0 on host cclcsup. > Load tape DailySet101 now > Continue [?/Y/n/t]? > ./users/andrew/ > amrecover> quit > 200 Good bye. > > ls -al > drwxr-xr-x 18 1029 203 1024 Jan 6 08:47 . > drwxr-xr-x 17 root sys 512 Dec 27 11:52 .. > drwxr-xr-x 3 andrew users 512 Jan 6 08:47 users > > ls -al users > total 3 > drwxr-xr-x 3 andrew users 512 Jan 6 08:47 . > drwxr-xr-x 18 1029 203 1024 Jan 6 08:47 .. > drwxr-xr-x 2 root sys 512 Jan 6 08:47 andrew > I may be missing something, but I see nothing unexpected in the above session. As John said above, thing come back relative to where you started amrecover. > > My guess is that the configure script detected the wrong tar. specifying > the location of tar with the --with-gnutar option works, as does > making a symlink of: /usr/local/bin/gtar -> /usr/local/bin/tar Possibility of finding a wrong version is why I always specify gnutar's location. I also rename it "amgtar" so it can easily be replaced with a different version or with a wrapper script and not affect the rest of the system. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
offsite strategies
Hi! I'm new to Amanda; I'm more used to "traditional" solutions like Networker or NetBackup. That being said, the setup I'm currently administrating has been put in place by my predecessor and I'm wondering if people are using Amanda in an "offsite" strategy, where there is one "cycle" of tapes offsite (usually a few weeks old) and another cycle residing onsite (ie. the current ongoing cycle). My point is that I would like to be able to store a full cycle offsite in case of a disaster so I can full rebuild all my machines without the worries of having only partials full backups. Any hints? Ciao, ..>David -- // david lebel // // http://www.lebel.org/ http://www.nobiaze.com/ // // pgp: 3633 6999 D47E 73ED 099F 4341 08A4 8E48 EF56 61D1 //
RE: offsite strategies
Suggest that you consider setting up a dump-cycle of 1 week, with a tape cycle of three weeks (5 tapes/15 tapes for weekdays only, 7/21 tapes for seven days-per-week cycles). This will permit you to send out a complete set of backup tapes once per week (for example, sending out the previous weeks tapes on Monday) and getting back the set of tapes from two weeks ago in exchange. You then start reusing the three week-old tapes for the current week. You will need to have three sets of tapes, in case it takes more than a day to exchange the tapes with your offsite repository. WeekIn-Use Off-SiteTo-Be-Reused 1 Set3 Set2Set1 2 Set1 Set3Set2 3 Set2 Set1Set3 4 Set3 Set2Set1 Because of the one-week dumpcycle, you will always have a complete set of dumps of each file system in the off-site tape set. It will grow increasingly out-of-date during the week, but storing your local collection of tapes in a fire-resistant vault should reduce your risks to an acceptable level. As always, "Your mileage may vary..." Don Donald L. (Don) Ritchey Unix System and Network Administrator E-mail: [EMAIL PROTECTED] -Original Message- From: David Lebel [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 12:19 PM To: [EMAIL PROTECTED] Subject: offsite strategies Hi! I'm new to Amanda; I'm more used to "traditional" solutions like Networker or NetBackup. That being said, the setup I'm currently administrating has been put in place by my predecessor and I'm wondering if people are using Amanda in an "offsite" strategy, where there is one "cycle" of tapes offsite (usually a few weeks old) and another cycle residing onsite (ie. the current ongoing cycle). My point is that I would like to be able to store a full cycle offsite in case of a disaster so I can full rebuild all my machines without the worries of having only partials full backups. Any hints? Ciao, ..>David -- // david lebel // // http://www.lebel.org/ http://www.nobiaze.com/ // // pgp: 3633 6999 D47E 73ED 099F 4341 08A4 8E48 EF56 61D1 // This e-mail and any of its attachments may contain Exelon Corporation proprietary information, which is privileged, confidential, or subject to copyright belonging to the Exelon Corporation family of Companies. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. Thank You.
Re: offsite strategies
We have 55 tapes in our rotation. We normally use 2-3 per day, and they rotate off site the day after they're used. Every morning 4-5 tapes come in the door to be over written. Amanda always makes sure there's at least one level 0 for each server in the current set, but we normally have two. So yes, it works well. Plan a rotation for yourself that makes sense, then stick to it religiously, including testing your restores. Is that what you're looking for? LP
Re: offsite strategies
[CC'ed to amanda-users] On Mon, Jan 06, 2003 at 01:18:42PM -0500, David Lebel wrote: > My point is that I would like to be able to store a full cycle offsite > in case of a disaster That's a good thing. > so I can full rebuild all my machines without the > worries of having only partials full backups. Ummm, I don't understand this. But anyway, I've seen people do what I think you want in two ways: 1) Assuming tapecycle=N*dumpcycle, keep N-1 dumpcycles worth of tapes offsite at all times, rotating the oldest dumpcycle in and the freshest out at the end of each dumpcycle. This can work pretty well if your offsite storage is convenient, flexible and reliable. If you burn the site down, you lose whatever you've got in the "current" dumpcycle. 2) Run two amanda configs; one "normal" that you run daily, and another 'dumpcycle 0'/'strategy noinc'/'record no' full-only type config that you run once per some-period and immediately send off-site. If you burn the site down, you lose all your "normal" tapes, but have your latest full-only tape(s). -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
Re: offsite strategies
Hi, On Jan 06, David Lebel wrote: | I'm new to Amanda; I'm more used to "traditional" solutions like | Networker or NetBackup. That being said, the setup I'm currently | administrating has been put in place by my predecessor and I'm wondering | if people are using Amanda in an "offsite" strategy, where there is one | "cycle" of tapes offsite (usually a few weeks old) and another cycle | residing onsite (ie. the current ongoing cycle). | | My point is that I would like to be able to store a full cycle offsite | in case of a disaster so I can full rebuild all my machines without the | worries of having only partials full backups. i think that the easiest way is to have two amanda configurations: * one regular configuration with N tapes residing onsite * one configuration for weekly/monthly/.. level 0 dumps for offsite There are different ways to get this to work nicely together, i think. My second configuration has "dumpcycle" and "runspercycle" set to 0, a high value for tapecycle, and runtapes > 1 Additionally, i set "record" to no so that the regular config still does level 0 dumps.
Re: offsite strategies
You could just rotate your older tapes offsite, making sure that you keep at least a dumpcycle's worth of tapes offsite. If you want something easier to restore from, set up a separate config that does fulls on everything(don't forget 'record no' or you'll confuse your regular config), run it weekly (or however current you need), and take those tapes offsite after each run. If you have two tape drives and plenty of tapes you could use the RAIT drivers in the latest version and mirror your normal backup tapes as you write them (has anyone actually tried this?). Frank --On Monday, January 06, 2003 13:18:42 -0500 David Lebel <[EMAIL PROTECTED]> wrote: Hi! I'm new to Amanda; I'm more used to "traditional" solutions like Networker or NetBackup. That being said, the setup I'm currently administrating has been put in place by my predecessor and I'm wondering if people are using Amanda in an "offsite" strategy, where there is one "cycle" of tapes offsite (usually a few weeks old) and another cycle residing onsite (ie. the current ongoing cycle). My point is that I would like to be able to store a full cycle offsite in case of a disaster so I can full rebuild all my machines without the worries of having only partials full backups. Any hints? Ciao, ..>David -- // david lebel // // http://www.lebel.org/ http://www.nobiaze.com/ // // pgp: 3633 6999 D47E 73ED 099F 4341 08A4 8E48 EF56 61D1 // -- Frank Smith [EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
saç programi
Title: E-mail message content Bayanlar Müjde Erkekler size de!!! Artik saçiniza daha el bile degmeden nasil bir saçin size yakisacagini bilgisayar ekraninda görebileceksiniz. Firmamizin yazmis oldugu program sayesinde seçkin kuaförlerde siz de bu ayricaliktan yararlanin. Kuaförünüzde bu program yoksa yinede üzülmeyin. Siz araci olun müsteri bulun iki kere kazanin. Hem hiçbir seye karismadan kârinizi alin hem de kendi kuaförünüzde bu hizmeti kullanin. www.ayronet.com adresinden indirebileceginiz demo versiyonda görebileceginiz gibi programimiz gayet anlasilir bir program olup 1750 farkli saç ve binlerce renk seçenegi sunar. Ayronet www.ayronet.com 0212 356 59 33
RE: offsite strategies
Donald's suggestion is precisely what we're doing here. We choose to send the most recent (runspercycle * runtapes) set offsite, as it is the most valuable. Others may choose to send an older set offsite so as to be able to restore accidental-deletions from the most recent set. Choose according to your environment. Cheers. At 01:29 PM 1/6/2003, [EMAIL PROTECTED] wrote: Suggest that you consider setting up a dump-cycle of 1 week, with a tape cycle of three weeks (5 tapes/15 tapes for weekdays only, 7/21 tapes for seven days-per-week cycles). This will permit you to send out a complete set of backup tapes once per week (for example, sending out the previous weeks tapes on Monday) and getting back the set of tapes from two weeks ago in exchange. You then start reusing the three week-old tapes for the current week. You will need to have three sets of tapes, in case it takes more than a day to exchange the tapes with your offsite repository. WeekIn-Use Off-SiteTo-Be-Reused 1 Set3 Set2Set1 2 Set1 Set3Set2 3 Set2 Set1Set3 4 Set3 Set2Set1 Because of the one-week dumpcycle, you will always have a complete set of dumps of each file system in the off-site tape set. It will grow increasingly out-of-date during the week, but storing your local collection of tapes in a fire-resistant vault should reduce your risks to an acceptable level. As always, "Your mileage may vary..." Don Donald L. (Don) Ritchey Unix System and Network Administrator E-mail: [EMAIL PROTECTED] -Original Message- From: David Lebel [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 12:19 PM To: [EMAIL PROTECTED] Subject: offsite strategies Hi! I'm new to Amanda; I'm more used to "traditional" solutions like Networker or NetBackup. That being said, the setup I'm currently administrating has been put in place by my predecessor and I'm wondering if people are using Amanda in an "offsite" strategy, where there is one "cycle" of tapes offsite (usually a few weeks old) and another cycle residing onsite (ie. the current ongoing cycle). My point is that I would like to be able to store a full cycle offsite in case of a disaster so I can full rebuild all my machines without the worries of having only partials full backups. Any hints? Ciao, ..>David -- // david lebel // // http://www.lebel.org/ http://www.nobiaze.com/ // // pgp: 3633 6999 D47E 73ED 099F 4341 08A4 8E48 EF56 61D1 // This e-mail and any of its attachments may contain Exelon Corporation proprietary information, which is privileged, confidential, or subject to copyright belonging to the Exelon Corporation family of Companies. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. Thank You. Darin Dugan System Administrator Iowa State University Extension [EMAIL PROTECTED] http://www.extension.iastate.edu
Re: offsite strategies
On Monday 06 January 2003 13:18, David Lebel wrote: >Hi! > >I'm new to Amanda; I'm more used to "traditional" solutions like >Networker or NetBackup. That being said, the setup I'm currently >administrating has been put in place by my predecessor and I'm > wondering if people are using Amanda in an "offsite" strategy, > where there is one "cycle" of tapes offsite (usually a few weeks > old) and another cycle residing onsite (ie. the current ongoing > cycle). > >My point is that I would like to be able to store a full cycle > offsite in case of a disaster so I can full rebuild all my > machines without the worries of having only partials full > backups. > >Any hints? > >Ciao, > ..>David I think what the schedule would look like would have to be determined by the dumpcycle and tapecycle values in the amanda.conf. This wouldn't be too hard to setup if you make sure cron nag-mails you on the days the tapes are to be exchanged with the offsite tapes. We as humans too soon forget a weekly chore. :( I'm just doing my home stuff here, but with a dumpcycle of 5 and a tapecycle of 28, I could move a considerable percentage of my tapes offsite, *if* I had an offsite. :) If you have amanda setup for a dumpcycle of 1 week, and at least 21 tapes in the tapecycle, you could have the middle weeks worth offsite with only one trip per week to exchange them. Since cleanliness is next to godliness, some sort of a well sealed carrier would be in order since autos are notorious for collecting trash. Here its not a huge problem. I keep them in their plastic bookpack carriers when not in the drives magazine, stuck in an oak pidgeonhole box on the wall I made a year or so back. Oak theoreticly isn't the best as its fumes have been known to attack blued gun finishes, but I've had no such problems here with the tapes coatings. Your trivia fact for the day. I haven't even had to run a cleaning tape in several months, so I must be doing something right :) -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.21% setiathome rank, not too shabby for a WV hillbilly
Re: offsite strategies
Quoting Darin Dugan ([EMAIL PROTECTED]): > Donald's suggestion is precisely what we're doing here. We choose to send > the most recent (runspercycle * runtapes) set offsite, as it is the most > valuable. Others may choose to send an older set offsite so as to be able > to restore accidental-deletions from the most recent set. Choose according > to your environment. What are your values for the following: dumpcycle runspercycle tapecycle x tapes ? Ciao, ...David -- // david lebel // // http://www.lebel.org/ http://www.nobiaze.com/ // // pgp: 3633 6999 D47E 73ED 099F 4341 08A4 8E48 EF56 61D1 //
backing up OS X with hfstar
Hello, I'm interesting in backing up an OS X client using Amanda. I've already read a couple of useful posts on this topic: http://www.bio.brandeis.edu/support/amandaonosx.txt http://groups.yahoo.com/group/amanda-users/message/40315 Both noted some problems and work arounds with using dump and restore, and the later recommended using "gnutar". I was surprised that neither mentioned "hfstar" which declares that it would work well with Amanda for backing up HFS volumes: http://www.metaobject.com/Community.html#hfstar Has anyone tried a backup and restore of an HFS volume with hfstar in the context of Amanda? Thanks! Mark http://mark.stosberg.com/
OSX and hfstar
[I stupidly deleted and expuged the email without replying to it. doh.] Looking at the hfstar package, I suspect this would work well. Simply compile your amanda-client with --with-gnutar=/usr/local/bin/hfstar (or similar) and give it a go. In fact, I'll toss this onto my testbed OSX box tonight (though I'll simply name the hfstar as gnutar...:) and see how it works. david --- david raistrick [EMAIL PROTECTED] http://www.expita.com/nomime.html
Re: offsite strategies
>I'm just doing my home stuff here, but with a dumpcycle of 5 and a >tapecycle of 28, I could move a considerable percentage of my tapes >offsite, *if* I had an offsite. :) Offsite could be as simple as your office (if you have one away from home), your mom's house, a bank deposit box, etc. When I worked at a certain small software company, offsite storage was me bringing home the .5" reels and stacking them in my closet 8^)
Re: offsite strategies
On Mon, Jan 06, 2003 at 01:29:09PM -0600, [EMAIL PROTECTED] wrote: > Suggest that you consider setting up a dump-cycle of 1 week, with a tape > cycle of three weeks (5 tapes/15 tapes for weekdays only, 7/21 tapes for > seven days-per-week cycles). This will permit you to send out a complete > set of backup tapes once per week (for example, sending out the previous > weeks tapes on Monday) and getting back the set of tapes from two weeks > ago in exchange. You then start reusing the three week-old tapes for the > current week. You will need to have three sets of tapes, in case it takes > more than a day to exchange the tapes with your offsite repository. > > WeekIn-Use Off-SiteTo-Be-Reused > > 1 Set3 Set2Set1 > 2 Set1 Set3Set2 > 3 Set2 Set1Set3 > 4 Set3 Set2Set1 > > > Because of the one-week dumpcycle, you will always have a complete set of > dumps of each file system in the off-site tape set. It will grow > increasingly out-of-date during the week, but storing your local collection > of tapes in a fire-resistant vault should reduce your risks to an > acceptable level. > A slight variation of this is a 4th set. You may have a need to recover very recent files and a need to keep a set off site. By not rotating off-site until a set has aged a week, you can keep the most recent set in-house at the cost of a week's older set off-site. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: offsite strategies
At 01:59 PM 1/6/2003, David Lebel wrote: Quoting Darin Dugan ([EMAIL PROTECTED]): > Donald's suggestion is precisely what we're doing here. We choose to send > the most recent (runspercycle * runtapes) set offsite, as it is the most > valuable. Others may choose to send an older set offsite so as to be able > to restore accidental-deletions from the most recent set. Choose according > to your environment. What are your values for the following: dumpcycle dumpcycle 1 weeks # the number of days in the normal dump cycle runspercycle runspercycle 5 # the number of amdump runs in dumpcycle days (We only run weekdays.) tapecycle x tapes tapecycle 15 tapes # the number of tapes in rotation (Exactly three weeks/dumpcycles worth.) And don't forget: runtapes 1 # number of tapes to be used in a single run of amdump (We use one tape per night.) So we rotate runspercycle * runtapes = 5 * 1 = 5 tapes off-site once per dumpcycle = 1 week. As I said before, we store the most recent set off-site as they are deemed the most valuable, and we don't restore too often. This has the side-effect of leaving the next dumpcycle worth of tapes on-site, so if you forget to switch things out, you still have the correct next tapes. Cheers. ? Ciao, ...David -- // david lebel // // http://www.lebel.org/ http://www.nobiaze.com/ // // pgp: 3633 6999 D47E 73ED 099F 4341 08A4 8E48 EF56 61D1 // Darin Dugan System Administrator Iowa State University Extension [EMAIL PROTECTED] http://www.extension.iastate.edu
mtx sources
I'm configuring Amanda 2.4.2 to access StorEdge 9 tape jukebox on Solaris 8. Much thanks to Darin Perusich. Unfortunately I'm unable to access ftp.estinc.com, the site given in the faq-o-matic as the mtx source site. DNS is not resolving the address. Is there an alternate source ? Is there a binary around someplace that I could grab ? thanks, Brian --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: Upgrade to 2.4.3 has hiccup -- I take it back
Doug> ... . Amanda didn't care if the exclude file was there or not, Doug> and actually gnu-tar didn't care very much either. Gnu-tar emits Doug> a warning that the exclude file doesn't exist, and so it won't Doug> use it. Jon> gnutar on my system terminates with an error if the exclude file Jon> is missing Jon> So I am surprised by Doug's observation to the contrary. I really should just learn to test things before I go off spouting stuff. Why is it always the case that when what I write differs from what I mean, it always turns out that what I write is wrong. Sigh. Gnu-tar dies when the exclude file doesn't exist. All version that I could fine too. BUT!!! AMANDA 2.4.2p2 ignores the missing exclude file if it doesn't exist. Here is a sendbackup file. Notice that sendbackup notices that the exclude file (//.amanda.excludes) doesn't exist, and so it ignores it. I still like this behavior, but now it is Amanda's sendbackup (and sendsize) that checkes for the existance of the exclude file, and in its absence it doesn't pass it to the backup command. /action goes slinking off the list in shame. sendbackup: debug 1 pid 85909 ruid 501 euid 501 start time Wed Jan 1 23:25:39 2003 /usr/local/libexec/amanda/sendbackup: version 2.4.2p2 sendbackup: got input request: GNUTAR / 1 2002:12:29:5:40:33 OPTIONS |;bsd-auth;compress-fast;index;exclude-list=.amanda.excludes; parsed request as: program `GNUTAR' disk `/' lev 1 since 2002:12:29:5:40:33 opt `|;bsd-auth;compress-fast;index;exclude-list=.amanda.excludes;' sendbackup: exclude list file "//.amanda.excludes" does not exist, ignoring sendbackup: try_socksize: send buffer size is 65536 sendbackup: stream_server: waiting for connection: 0.0.0.0.50001 sendbackup: stream_server: waiting for connection: 0.0.0.0.50002 sendbackup: stream_server: waiting for connection: 0.0.0.0.50003 waiting for connect on 50001, then 50002, then 50003 sendbackup: stream_accept: connection from 10.10.10.15.5 sendbackup: stream_accept: connection from 10.10.10.15.50001 sendbackup: stream_accept: connection from 10.10.10.15.50004 got all connections sendbackup: spawning /usr/bin/gzip in pipeline sendbackup: argument list: /usr/bin/gzip --fast sendbackup-gnutar: pid 85910: /usr/bin/gzip --fast sendbackup-gnutar: doing level 1 dump as listed-incremental from /var/amanda/lists/birdland__0 to /var/amanda/lists/birdland__1.new sendbackup-gnutar: doing level 1 dump from date: 2002-12-29 5:40:33 GMT sendbackup: spawning /usr/local/libexec/amanda/runtar in pipeline sendbackup: argument list: gtar --create --file - --directory / --one-file-system --listed-incremental /var/amanda/lists/birdland__1.new --sparse --ignore-failed-read --totals . sendbackup-gnutar: /usr/local/libexec/amanda/runtar: pid 85912 sendbackup: started index creator: "/usr/local/bin/gtar -tf - 2>/dev/null | sed -e 's/^\.//'" sendbackup: index created successfully sendbackup: pid 85909 finish time Wed Jan 1 23:25:40 2003
Re: mtx sources
It's on sourceforge, http://sourceforge.net/projects/mtx Frank --On Monday, January 06, 2003 16:46:02 -0500 Brian Cuttler <[EMAIL PROTECTED]> wrote: I'm configuring Amanda 2.4.2 to access StorEdge 9 tape jukebox on Solaris 8. Much thanks to Darin Perusich. Unfortunately I'm unable to access ftp.estinc.com, the site given in the faq-o-matic as the mtx source site. DNS is not resolving the address. Is there an alternate source ? Is there a binary around someplace that I could grab ? thanks, Brian --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773 -- Frank Smith [EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Kıbrıs Sorunu Türkiye 'ye Engel mi?
TürkAnket Haftalýk AnketiAnkete Katýlmak Ýçin Oy Vermek ÝstediðinizKutuyu Seçip Tamam Butonuna BasýnýzSizce Kýbrýs Sorunu Türkiye 'nin Geniþleme Sürecine Engel Teþkil Ediyor mu?Evet Engel OluyorHayýr Engel Olmuyor
Re: Upgrade to 2.4.3 has hiccup -- I take it back
On Mon, Jan 06, 2003 at 04:15:52PM -0600, Douglas K. Rand wrote: > > I really should just learn to test things before I go off spouting > stuff. Why is it always the case that when what I write differs from > what I mean, it always turns out that what I write is wrong. Sigh. We both suffer in shame :)) > BUT!!! AMANDA 2.4.2p2 ignores the missing exclude file if it doesn't > exist. Here is a sendbackup file. Notice that sendbackup notices that > the exclude file (//.amanda.excludes) doesn't exist, and so it ignores > it. > > I still like this behavior, but now it is Amanda's sendbackup (and > sendsize) that checkes for the existance of the exclude file, and in > its absence it doesn't pass it to the backup command. I don't mind that, but I think a warning should be printed at some point rather than have to notice in a debug file that I misspeeled .amanda.exclude. Is there some notice given? In fact, if that sendbackup behavior still exists in 2.4.3 (I suspect it does), then I think the new amcheck notice should be a warning, not an error. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Upgrade to 2.4.3 has hiccup -- I take it back
>> I still like this behavior, but now it is Amanda's sendbackup (and >> sendsize) that checkes for the existance of the exclude file, and >> in its absence it doesn't pass it to the backup command. Jon> I don't mind that, but I think a warning should be printed at Jon> some point rather than have to notice in a debug file that I Jon> misspeeled .amanda.exclude. Is there some notice given? Jon> In fact, if that sendbackup behavior still exists in 2.4.3 (I Jon> suspect it does), then I think the new amcheck notice should be a Jon> warning, not an error. Personally, I don't have a problem with the warning only being in the sendsize or sendbackup diagnostic files. I use the amcheck -m alot and have the output sent to my pager, so I wouldn't want it to always warn me of those, and even if I missed changing a tape, I might not want all those warnings. But thats just my $0.02.
Re: mtx sources
Actually, he moved it to mtx.badtux.net.but the sourceforge site should redirect you. =G= Frank Smith wrote: It's on sourceforge, http://sourceforge.net/projects/mtx Frank --On Monday, January 06, 2003 16:46:02 -0500 Brian Cuttler <[EMAIL PROTECTED]> wrote: I'm configuring Amanda 2.4.2 to access StorEdge 9 tape jukebox on Solaris 8. Much thanks to Darin Perusich. Unfortunately I'm unable to access ftp.estinc.com, the site given in the faq-o-matic as the mtx source site. DNS is not resolving the address. Is there an alternate source ? Is there a binary around someplace that I could grab ? thanks, Brian --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773 -- Frank Smith [EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
amadmin and amplot analysis
I am starting to look at the utilities amadmin and amplot. The following is my attempt to get some perspective on post analysis. Has anyone has written notes/docs related to the display of AMANDA's data metrics or performed post-analysis of the data? If so, I would like to read them. I noticed that the output of the following amadmin command differed substantially between versions 2.4.2 and 2.4.3-20030104. For example: amadmin amdump.1 2.4.2 produced m,any lines of output, such as: amplot -e amdump.1 Displaying graph on the screen, for next graph 20030103 INFO# dumper: dgram_bind: socket bound to 0.0.0.0.537 20030103 INFO# dumper: dgram_bind: socket bound to 0.0.0.0.539 20030103 INFO# dumper: dgram_bind: socket bound to 0.0.0.0.538 20030103 INFO# dumper: dgram_bind: socket bound to 0.0.0.0.541 20030103 INFO# dumper: stream_client: connected to 128.3.132.16.34299 20030103 INFO# dumper: stream_client: our side is 0.0.0.0.1538 20030103 INFO# dumper: stream_client: connected to 128.3.132.16.34300 20030103 INFO# dumper: stream_client: our side is 0.0.0.0.1539 20030103 INFO# dumper: stream_client: connected to 128.3.132.16.34301 20030103 INFO# dumper: stream_client: our side is 0.0.0.0.1540 20030103 INFO# dumper: stream_client: connected to 128.3.28.26.4379 20030103 INFO# dumper: stream_client: our side is 0.0.0.0.1541 20030103 INFO# dumper: stream_client: connected to 128.3.28.26.4380 20030103 INFO# dumper: stream_client: our side is 0.0.0.0.1542 20030103 INFO# dumper: stream_client: connected to 128.3.28.26.4381 20030103 INFO# dumper: stream_client: our side is 0.0.0.0.1543 20030103 INFO# dumper: stream_client: connected to 128.3.28.25.1544 20030103 INFO# dumper: stream_client: our side is 0.0.0.0.1548 20030103 INFO# dumper: stream_client: connected to 128.3.132.98.1124 20030103 INFO# dumper: stream_client: our side is 0.0.0.0.1547 [ 80+ lines deleted for brevity ] 20030103 INFO# dumper: stream_client: connected to 128.3.28.25.1659 20030103 INFO# dumper: stream_client: our side is 0.0.0.0.1662 20030103 INFO# dumper: stream_client: connected to 128.3.28.25.1660 20030103 INFO# dumper: stream_client: our side is 0.0.0.0.1663 Longest dumping hosts Times 10800 Host:disk/levstart - end = run => total redbelly:/net/adder/scratch2/2 0:14:50 - 0:14:51 = 0:00:01 redbelly:/usr/local_redbelly/etc/1 0:15:05 - 0:15:06 = 0:00:01 redbelly:/etc/1 0:15:47 - 0:15:47 = 0:00:00 redbelly:/var/amanda/1 0:16:01 - 0:16:03 = 0:00:02 redbelly:/net/redbelly/lanl1/1 0:16:17 - 0:16:20 = 0:00:03 redbelly:/net/redbelly/home1/1 0:16:31 - 0:16:40 = 0:00:09 redbelly:/net/adder/scratch1/0 0:16:46 - 2:38:27 = 2:21:41 redbelly:/net/redbelly/lbnl1/0 2:38:28 - 5:04:48 = 2:26:20 => 4:48:17 anaconda:/etc/1 0:14:51 - 0:14:52 = 0:00:01 anaconda:/net/anaconda/scratch1/1 0:15:07 - 0:15:47 = 0:00:40 => 0:00:41 Whereas, with the 2.4.3-20030104 version, the output did not display that stuff above. amplot -e amdump.1 Displaying graph on the screen, for next graph Longest dumping hosts Times 10800 Host:disk/levstart - end = run => total redbelly:2/1048576 0:14:50 - 0:14:51 = 0:00:01 redbelly:1/1048576 0:15:05 - 0:15:06 = 0:00:01 redbelly:1/1048576 0:15:47 - 0:15:47 = 0:00:00 redbelly:1/1048576 0:16:01 - 0:16:03 = 0:00:02 redbelly:1/1048576 0:16:17 - 0:16:20 = 0:00:03 redbelly:1/1048576 0:16:31 - 0:16:40 = 0:00:09 redbelly:0/1048576 0:16:46 - 2:38:27 = 2:21:41 redbelly:0/1048576 2:38:28 - 5:04:48 = 2:26:20 => 4:48:17 anaconda:1/1048576 0:14:51 - 0:14:52 = 0:00:01 anaconda:1/1048576 0:15:07 - 0:15:47 = 0:00:40 => 0:00:41 ### Just thought I would share these differences... in case it meant something to someone. ## I am just looking for general info about how amadmin and amplot can be used. (like wrapping them in a larger script). One thing I noticed with amplot was the fact that the X window never showed on the screen... I suppose more experimentation is in order... :) Also, has anyone written analysis scripts that evaluate multiple amdump runs? thank you... dk PS: and before anyone asks, my mail client seems to be broken.. sorry for the long lines.
