BackupPC 1.5.0 released (backup to disk for WinXX/Linux)
BackupPC version 1.5.0 has been released on SourceForge, see http://backuppc.sourceforge.net. BackupPC a high-performance perl-based package for backing up linux, unix or WinXX PCs and laptops to a server's disk. BackupPC is highly configurable and easy to install and maintain. No client SW is needed. Given the ever decreasing cost of disks and raid systems, it is now practical and cost effective to backup a large number of machines onto a server's local disk or network storage. This is what BackupPC does. BackupPC can be used as a complement to Amanda, for example to stage backups from many desktop machines prior to dumping onto tape. Key features are pooling of identical files (big savings in server disk space), compression, support for DHCP clients, and a comprehensive CGI interface that allows users to browse backups and restore files. BackupPC is free software distributed under a GNU GPL license. BackupPC runs on linux or unix servers, and has been tested on linux, Win95, Win98, Win2000 and WinXP clients. Enjoy! Craig Barratt
Re: dd gets tape native capacity, amanda (sometimes) dosen't
On Sat, Aug 10, 2002 at 12:08:43AM -0400, Jon LaBadie wrote: > > Pulling individual lines from a long message: > > On Fri, Aug 09, 2002 at 03:37:32PM -0600, Will Aoki wrote: > > > Some nights, to some tapes, my backups run fine. I get about 8 GB dumped > > to tape: > > > > But other days, to other tapes, I run out of tape at about 5 GB: > > > > Note this line from your failed report: > > > taper: tape umnh-2002-1 kb 9590432 fm 33 writing file: No space left on >device > > It says 9.6GB of data plus 33 file marks were written before the error. Not 5GB. > > Now, your file system by file system list shows an output size (after compression) > of 5.3GB plus one failed file system. Those 5.3GB were "successfully written" as > evidenced by the completed "taper" statistics. > > My guess about the failed entry is that it is a very large file system, more than 4GB > after compression. That seems to be it. I've been misreading the report - since the STATISTICS section is actually only reporting successfully dumped data, I thought that much less data was getting to tape than actually was. Someone seems to have killed my .amandaexclude for the failing filesystem between when the filesystem was being dumped successfully and when it started failing, bloating a 2.5 GB volume to 8.5 GB. I'm pretty sure I know who it was, since there's only one other person with the neccessary access privs to do the deed, and he was cleaning up cruft around the time my backups started failing... I've recreated the exclude file, so I expect that tonight's backup will be successful. Thanks for your help! > Further, I think there is insufficient holding disk space to receive that system >dump. > Thus it was being dumped directly to tape. I say this because there is no dumper > data. A dump to the holding disk must complete before transfer to tape begins. As > taping was in progress, yet there is no dumper data, the dump must be going directly > to tape. Otherwise there would be dumper data and dumps left on the holding disk > available for amflush. > > Basically some days you are backing up more data than a single tape can hold and are >not > using multiple tapes per run. Plus, some of your systems will not fit the holding >disk. > About the holding disk space, how big is it and what percent is "reserved"? Only 2GB, with 'reserve 60'. I'm hoping to get more after Tuesday's mission to scavenge parts from the junk computers my department has left in the building's heating / service tunnel. -- William Aoki [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign B1FB C169 C7A6 238B 280B <- key change\ / No HTML in mail or news! 99AF A093 29AE 0AE1 9734 prev. expiredX / \
Re: core dump of chg-scsi under Solaris 9
Thanks for all the help. The problem goes away as soon as I used the following device (in changer.conf). changerdev /dev/scsi/changer/c1t5d1 This device is created by sgen and not by st. I'll write a summary with what I did as soon as I got amanda completely up and running. Sven
Re: amrecover problem
On Wed, Jul 17, 2002 at 05:19:16PM +0100, Mark Snelling wrote: > I have a problem with amanda. It seems to back up my filesystems ok (except > for the warning below). When I run amrecover, 2 of the filesystems I can > browse through, but /mnt/data has the directory structure and NO files?! Has > anyone any idea whats going on? [clip] > FAILED AND STRANGE DUMP DETAILS: > > /-- hades /mnt/data lev 0 STRANGE > sendbackup: start [hades:/mnt/data level 0] > sendbackup: info BACKUP=/bin/tar > sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... - > sendbackup: info COMPRESS_SUFFIX=.gz > sendbackup: info end > ? gtar: ./home/dannyb/.Maildir/cur/1026897042.12092_1.hades,S=1602\:2,S: > Warning: Cannot stat: No such file or directory > | Total bytes written: 28790016000 (27GB, 1.5MB/s) The STRANGE warning is solely due to some wacko thing your user dannyb has down in his qmail delivery directory. It should do no harm, but you probably want to go clean it out. > sendbackup: size 28115250 So *plenty* of files there, even if amrecover isn't letting you see 'em. :-) You can amrestore and confirm the data is actually there, that always makes me sleep better. amrecover doesn't run 'gtar -tv' on the tape, it just unzips what's in the index file (under /var/adm/amanda/config_name/index for me). The most common cause of bad indexes is bad versions of GNU tar. Do: % /bin/tar --version You want to see 1.13.19 or 1.13.25. If you don't, build & install 1.13.25 from: http://www.funet.fi/pub/gnu/alpha/gnu/tar/ MAKE SURE you install it where amanda expects to find it! If your tar version is already good, I'm out of ideas. [clip] > DUMP SUMMARY: > DUMPER STATSTAPER STATS > HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s > -- - > hades/ 0 988980 410048 41.5 7:08 957.6 7:08 957.1 > hades/boot 04900 2848 58.1 0:031097.0 0:031027.5 > hades/mnt/data 0 2811525022508256 80.1 297:321260.8 297:331260.8 Nothing to do w/your problem, but you might want to try a columnspec: columnspec "HostName=0:10,Disk=1:10,OrigKB=1:9,OutKB=1:9,DumpRate=1:7,TapeRate=1:7" or something similar, makes the summary output nice & pretty. -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
unsubscribe
unsubscribe
amrecover problem
I have a problem with amanda. It seems to back up my filesystems ok (except
for the warning below). When I run amrecover, 2 of the filesystems I can
browse through, but /mnt/data has the directory structure and NO files?! Has
anyone any idea whats going on?
Here is the report generated by amanda:
These dumps were to tape DAILY01-1.
The next tape Amanda expects to use is: a new tape.
FAILURE AND STRANGE DUMP SUMMARY:
hades /mnt/data lev 0 STRANGE
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)1:06
Run Time (hrs:min) 6:20
Dump Time (hrs:min)5:05 5:05 0:00
Output Size (meg) 22383.922383.90.0
Original Size (meg) 28426.928426.90.0
Avg Compressed Size (%)78.7 78.7--
Filesystems Dumped3 3 0
Avg Dump Rate (k/s) 1253.7 1253.7--
Tape Time (hrs:min)5:05 5:05 0:00
Tape Size (meg) 22384.022384.00.0
Tape Used (%) 64.0 64.00.0
Filesystems Taped 3 3 0
Avg Tp Write Rate (k/s) 1253.6 1253.6--
FAILED AND STRANGE DUMP DETAILS:
/-- hades /mnt/data lev 0 STRANGE
sendbackup: start [hades:/mnt/data level 0]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
? gtar: ./home/dannyb/.Maildir/cur/1026897042.12092_1.hades,S=1602\:2,S:
Warning: Cannot stat: No such file or directory
| Total bytes written: 28790016000 (27GB, 1.5MB/s)
sendbackup: size 28115250
sendbackup: end
\
NOTES:
planner: Adding new disk hades:/boot.
planner: Adding new disk hades:/.
planner: Adding new disk hades:/mnt/data.
taper: tape DAILY01-1 kb 22921248 fm 3 [OK]
DUMP SUMMARY:
DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- -
hades/ 0 988980 410048 41.5 7:08 957.6 7:08 957.1
hades/boot 04900 2848 58.1 0:031097.0 0:031027.5
hades/mnt/data 0 2811525022508256 80.1 297:321260.8 297:331260.8
(brought to you by Amanda version 2.4.2p2)
Re: core dump of chg-scsi under Solaris 9
On Sunday 11 August 2002 09:14, Sven Kirmess wrote: >Gene Heskett wrote: >> I take it you unpacked, made, and installed amanda as root. >> Generally speaking, thats a no-no. > >Yes I did. But that's only for a quick test... It should not be > relevant It's extremely revelant. >who builds the code (only for security considerations). (Or am I > wrong)? Amanda is never run as root because amanda does its own suid when it needs to, which may well cause amanda to segfault when amanda finds out she is already root. >If a segfault occoures the code is clear buggy. I segfault should > never occour. The coredump I don't know about. Here it refuses to run amcheck as root, returning this: [root@coyote root]# amcheck DailySet1 amcheck: running as user "root" instead of "amanda" [root@coyote root]# Now, lets see if I have a fresh core in /root... No, that was a clean exit. But then it was also properly built code from the last amanda-2.4.3b3-20020805 snapshot. Please don't blame the code if its not properly built. Doing so is unfair both to amanda, and to you, who feel like you have got to poormouth amanda when it doesn't work according to your ideas. Thats not only unfair, it also shows a lack of perusing the docs that come with her. Please do so. > >I used these (and more) configure options >--with-user=amanda --with-group=amanda Amanda's group needs to be some group with disk access, which is why many of us choose to use the user 'disk' as amanda's group. It seems like there is some sort of poetic license in that... In any event, user amanda has no real rights inherited from group amanda. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.11% setiathome rank, not too shabby for a WV hillbilly
Re: core dump of chg-scsi under Solaris 9
Gene Heskett wrote: > I take it you unpacked, made, and installed amanda as root. > Generally speaking, thats a no-no. Yes I did. But that's only for a quick test... It should not be relevant who builds the code (only for security considerations). (Or am I wrong)? If a segfault occoures the code is clear buggy. I segfault should never occour. I used these (and more) configure options --with-user=amanda --with-group=amanda Sven
