Re: dump and soft-updates question
"Gema niskazhu" writes: > Hi! > > I-ve got a question about dump | restore on soft-updates managed slice. > > When we dump smth on soft updates slice where it actualy(mechanicaly) dump > it? The output of the dump is controlled by a command-line switch (-f). In the absence of the switch, it defaults to $RMT, but that is rarely applicable any more. Soft updates do not affect this. > Because I-ve forgot to turn of soft-updates off on my backup hdd and dump > img on it =) That is not an issue. Dumping a live filesystem is, but having soft upates active on the filesystem does not make things significantly worse than they would have been anyway. > After that i vas quet surprised because it ate 16 Gigs of / but du\df cant > show anything about. Can you be more specific? Where were you dumping to? > what is situated in this 16 Gigs. Is it possible that your dump went to /dev/rmt because you failed to supply an alternative destination? -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: dump and restore
Peter Boosten <[EMAIL PROTECTED]> writes: > Malcolm Kay wrote: >> On Sat, 19 Jul 2008 06:51 am, Peter Boosten wrote: >>> >>> The /usr/ partition was 74Gb, and it took (according to dump >>> 52631 seconds (~ 14.5 hours) to copy. Both disks are IDE, in >>> the same machine on different IDE controllers. >>> >> The time for dump/restore normally depends more on the occupancy of >> the partition than its actual size. This is one reason why we avoid >> using dd for this purpose as we must then copy the entire >> 74Gb rather than just that used. >> > > Hmmm, I didn't even know it was possible to dump a partition > unmounted. Try that next time then. The actual partition size was > ~200GB, but around 74Gb data. If you can, it's always *much* preferable to dump an unmounted partition. I suspect your problems here had more to do with the bad disk, though. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump and restore
Malcolm Kay wrote: On Sat, 19 Jul 2008 06:51 am, Peter Boosten wrote: The /usr/ partition was 74Gb, and it took (according to dump 52631 seconds (~ 14.5 hours) to copy. Both disks are IDE, in the same machine on different IDE controllers. The time for dump/restore normally depends more on the occupancy of the partition than its actual size. This is one reason why we avoid using dd for this purpose as we must then copy the entire 74Gb rather than just that used. Hmmm, I didn't even know it was possible to dump a partition unmounted. Try that next time then. The actual partition size was ~200GB, but around 74Gb data. Thanks all for your answers. Peter -- http://www.boosten.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump and restore
On Sat, 19 Jul 2008 06:51 am, Peter Boosten wrote: > Hi all, > > My harddisk was failing and I wanted the data copied to > another disk, but since my original wouldn't boot, I installed > a minimal FreeBSD on the new disk, mounted the old partitions > under /mnt and copied from the original to the new partitions > by using: > > dump 0af - /dev/ad2s1[adef] | restore xf - > > (the partitions adef where done one by one) > > The /usr/ partition was 74Gb, and it took (according to dump > 52631 seconds (~ 14.5 hours) to copy. Both disks are IDE, in > the same machine on different IDE controllers. > The time for dump/restore normally depends more on the occupancy of the partition than its actual size. This is one reason why we avoid using dd for this purpose as we must then copy the entire 74Gb rather than just that used. > Is it normal for a backup/restore to take this long? Or could > this be due to my failing disk? > > Peter Malcolm ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump and restore
since my original wouldn't boot, I installed a minimal FreeBSD on the new disk, mounted the old partitions under /mnt and copied from the original to the new partitions by using: dump 0af - /dev/ad2s1[adef] | restore xf - (the partitions adef where done one by one) The /usr/ partition was 74Gb, and it took (according to dump 52631 seconds (~ 14.5 hours) to copy. Both disks are IDE, in the same machine on different IDE controllers. Is it normal for a backup/restore to take this long? Or could this be due to my failing disk? if you don't use softdeps on destination disk - it will. or if it had so slow reads because of hardware problem. rather be happy it succeeded :) if your disk is failing ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump and restore
On Fri, Jul 18, 2008 at 11:21:26PM +0200, Peter Boosten wrote: > Hi all, > > My harddisk was failing and I wanted the data copied to another disk, > but since my original wouldn't boot, I installed a minimal FreeBSD on > the new disk, mounted the old partitions under /mnt and copied from the > original to the new partitions by using: > > dump 0af - /dev/ad2s1[adef] | restore xf - > > (the partitions adef where done one by one) > > The /usr/ partition was 74Gb, and it took (according to dump 52631 > seconds (~ 14.5 hours) to copy. Both disks are IDE, in the same machine > on different IDE controllers. > > Is it normal for a backup/restore to take this long? Or could this be > due to my failing disk? When dumping to a file it should not take this long. But in this case it might be that dump is waiting for restore, since the space in a pipe is not infinite. Also, when dumping mounted partitions you should use the -L flag with dump. But in a case like this there is little reason to mount the old partitions. If the failing disk was giving trouble, you might find errors in /var/log/messages. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpmKtzKlogpz.pgp Description: PGP signature
Re: dump and remote file fetching
What I do : Allow ssh access only using key "PubkeyAuthentication yes" Allow root access Create a root ssh Pubkey Automate the access using any script based on ssh… If you want to be more restrictive, you can deploy a firewall localy on your server and limit ssh access to one or more selected IPs. Bye // Le 28 mai 08 à 07:53, Zbigniew Szalbot a écrit : Hi there, Need a word of advice. I use dump to backup my data. All fine. Dump saves compressed *.bz2 files. Nice. All I need now is a way to copy them from the server to a remote backup machine. The problem I am facing is that bz2 files are owned by root:wheel. So if I use scp [EMAIL PROTECTED]:/path/to/*.bz2, it does not have sufficient permissions to fetch the files. I can use sudo, but then I need to interactively type the password, which I would like to avoid. Can you suggest simple ways of getting around this? I don't mind using special tools for the job, especially if they are not too complicated... :) Before firing this email off I took a look at rsync and it seems easy enough to do just what I need but still many thanks for suggestions! I have been very happy with rsnapshot. Take that for a spin and see how it works for you I have taken a look at rsnapshot but it seems I am left to deal with the same problem: From their page: In addition to full paths on the local filesystem, you can also backup remote systems using rsync over ssh. If you have ssh installed and enabled (via the cmd_ssh parameter), you can specify a path like: backup [EMAIL PROTECTED]:/etc/ example.com/ This behaves fundamentally the same way, but you must take a few extra things into account. a/ The ssh daemon must be running on example.com b/ You must have access to the account you specify the remote machine, in this case the root user on example.com. I do not allow remote root login so what are my options in that case? How do you deal with such a scenario? Many thanks! -- Zbigniew Szalbot www.lc-words.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED] " Gregober ---> PGP ID --> 0x1BA3C2FD bsd @at@ todoo.biz P "Please consider your environmental responsibility before printing this e-mail" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump and remote file fetching
Zbigniew Szalbot wrote: Hello, Need a word of advice. I use dump to backup my data. All fine. Dump saves compressed *.bz2 files. Nice. All I need now is a way to copy them from the server to a remote backup machine. The problem I am facing is that bz2 files are owned by root:wheel. So if I use scp [EMAIL PROTECTED]:/path/to/*.bz2, it does not have sufficient permissions to fetch the files. I can use sudo, but then I need to interactively type the password, which I would like to avoid. Add user "user" to a group "xyz". Arrange for dump files to get group "xyz" and permissions g+w. You can probably do this by changing the group of the directory the dumps are written into and setting the sticky bit. Can you suggest simple ways of getting around this? I don't mind using special tools for the job, especially if they are not too complicated... :) Before firing this email off I took a look at rsync and it seems easy enough to do just what I need but still many thanks for suggestions! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump and remote file fetching
On Wed, May 28, 2008 at 9:53 AM, Zbigniew Szalbot <[EMAIL PROTECTED]> wrote: > Hi there, > > Need a word of advice. I use dump to backup my data. All fine. Dump saves >>> compressed *.bz2 files. Nice. All I need now is a way to copy them from the >>> server to a remote backup machine. The problem I am facing is that bz2 files >>> are owned by root:wheel. So if I use scp [EMAIL PROTECTED]:/path/to/*.bz2, >>> it does not have sufficient permissions to fetch the files. I can use sudo, >>> but then I need to interactively type the password, which I would like to >>> avoid. >>> >>> Can you suggest simple ways of getting around this? I don't mind using >>> special tools for the job, especially if they are not too complicated... :) >>> >>> Before firing this email off I took a look at rsync and it seems easy >>> enough to do just what I need but still many thanks for suggestions! >>> >> >> I have been very happy with rsnapshot. Take that for a spin and see how >> it works for you >> > > I have taken a look at rsnapshot but it seems I am left to deal with the > same problem: > > From their page: > In addition to full paths on the local filesystem, you can also backup > remote systems using rsync over ssh. If you have ssh installed and enabled > (via the cmd_ssh parameter), you can specify a path like: > > backup [EMAIL PROTECTED]:/etc/ example.com/ > > This behaves fundamentally the same way, but you must take a few extra > things into account. > > a/ The ssh daemon must be running on example.com > b/ You must have access to the account you specify the remote machine, in > this case the root user on example.com. > > I do not allow remote root login so what are my options in that case? How > do you deal with such a scenario? Many thanks! HI ZS, I used to do something like this with a very simple shell script, using ftp. In the script, I was simply checking the filename, extracting the date from it, comparing the date with today's date, and pushing into a nother server all files that are dated yesterday. These were log files created using another script, which would create them like main.MMDD.log. IIRC, ftp relies on a file ~/.netrc which can have the destination hostname, username and password. With these, ftp will be automated - no need to enter any logon credentials. Please read the man page for ftp on how to use the netrc file or the ~/.netrc If you need more assistance, find me off list:-) Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Oh My God! They killed init! You Bastards!" --from a /. post ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump and remote file fetching
Hi there, Need a word of advice. I use dump to backup my data. All fine. Dump saves compressed *.bz2 files. Nice. All I need now is a way to copy them from the server to a remote backup machine. The problem I am facing is that bz2 files are owned by root:wheel. So if I use scp [EMAIL PROTECTED]:/path/to/*.bz2, it does not have sufficient permissions to fetch the files. I can use sudo, but then I need to interactively type the password, which I would like to avoid. Can you suggest simple ways of getting around this? I don't mind using special tools for the job, especially if they are not too complicated... :) Before firing this email off I took a look at rsync and it seems easy enough to do just what I need but still many thanks for suggestions! I have been very happy with rsnapshot. Take that for a spin and see how it works for you I have taken a look at rsnapshot but it seems I am left to deal with the same problem: From their page: In addition to full paths on the local filesystem, you can also backup remote systems using rsync over ssh. If you have ssh installed and enabled (via the cmd_ssh parameter), you can specify a path like: backup [EMAIL PROTECTED]:/etc/ example.com/ This behaves fundamentally the same way, but you must take a few extra things into account. a/ The ssh daemon must be running on example.com b/ You must have access to the account you specify the remote machine, in this case the root user on example.com. I do not allow remote root login so what are my options in that case? How do you deal with such a scenario? Many thanks! -- Zbigniew Szalbot www.lc-words.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dump and restore for Windows partitions
On Jan 30, 2008 2:08 PM, Roland Smith <[EMAIL PROTECTED]> wrote: > On Wed, Jan 30, 2008 at 09:18:53AM -0500, Martin Boulianne wrote: > > Hi, > > Maybe this is a dumb question, but I was wondering if I could use > > dump (and restore) on Windows NTFS partitions. > > > > Say I have a NTFS partition, ad0s1. Could I use: > ># dump -b 4 -f /backups/winxp.dump /dev/ad0s1 > > Dump is only suited for FreeBSD's native UFS filesystem. > > > Or after a restore, Windows would be able to read the files? What about dd, > > with something like: > ># dd if=/dev/ad0s1 of=/backups/winxp.bck bs=4k > > This should work, I think. But it will take up a lot of space, because > it will copy the every sector (even unused ones). > > Unless there are special features of NTFS that you use, you could mount > the volume, and make a backup with zip(1) or tar(1). Note that with this > method > you will probably lose any NTFS attributes. > > The port sysutils/ntfsprogs contains programs like ntfsclone and > ntfscp. Maybe those can be of use? > > Probably the best tool to completely backup an NTFS partition is a > windows-based tool. > > Roland > -- > R.F.Smith http://www.xs4all.nl/~rsmith/ > [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] > pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) > Hi Roland, Well, from its man pages, ntfsclone seems very promising!! If it is restored to a different partition than the one it was backuped from, Windows won't boot. But that's easy to fix... Anyway it's for backup purpose, so I shall use it on the same partition. Moreover, I use FreeBSD's boot manager, so I don't give a crap =P Thanks! =) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dump and restore for Windows partitions
On Wed, Jan 30, 2008 at 09:18:53AM -0500, Martin Boulianne wrote: > Hi, > Maybe this is a dumb question, but I was wondering if I could use > dump (and restore) on Windows NTFS partitions. > > Say I have a NTFS partition, ad0s1. Could I use: ># dump -b 4 -f /backups/winxp.dump /dev/ad0s1 Dump is only suited for FreeBSD's native UFS filesystem. > Or after a restore, Windows would be able to read the files? What about dd, > with something like: ># dd if=/dev/ad0s1 of=/backups/winxp.bck bs=4k This should work, I think. But it will take up a lot of space, because it will copy the every sector (even unused ones). Unless there are special features of NTFS that you use, you could mount the volume, and make a backup with zip(1) or tar(1). Note that with this method you will probably lose any NTFS attributes. The port sysutils/ntfsprogs contains programs like ntfsclone and ntfscp. Maybe those can be of use? Probably the best tool to completely backup an NTFS partition is a windows-based tool. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpcUE6ka1gui.pgp Description: PGP signature
Re: Dump and restore for Windows partitions
On Wed, Jan 30, 2008 at 09:18:53AM -0500, Martin Boulianne wrote: > Hi, > Maybe this is a dumb question, but I was wondering if I could use > dump (and restore) on Windows NTFS partitions. > > Say I have a NTFS partition, ad0s1. Could I use: ># dump -b 4 -f /backups/winxp.dump /dev/ad0s1 Well, I htink it would work for a FATnn slice, but I don't know about NTFS. > Or after a restore, Windows would be able to read the files? What about dd, > with something like: ># dd if=/dev/ad0s1 of=/backups/winxp.bck bs=4k The problem is that dd copies essentially byte-by-byte and so it might not restore in the fashion you wish. Label blocks and file links would all have to be identical - which they might not be in a real life situation. But, give it a try. Copy it with dd and then restore it with dd back to a different slice and see what happens. jerry > > Thanks!! =) > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dump and restore for Windows partitions
Martin Boulianne wrote: Maybe this is a dumb question, but I was wondering if I could use dump (and restore) on Windows NTFS partitions. Say I have a NTFS partition, ad0s1. Could I use: # dump -b 4 -f /backups/winxp.dump /dev/ad0s1 No. Dump is specific to ufs/ufs2 filesystems. It specifically knows the format of the filesystem (superblocks, inodes, directories etc). You just get an error if you try: (cartman)103% dump -0 -f /tmp/foo /windows DUMP: Date of this level 0 dump: Wed Jan 30 15:23:25 2008 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/ad4s1 (/windows) to /tmp/foo DUMP: Cannot find file system superblock DUMP: The ENTIRE dump is aborted. I don't know if there are NTFS utils running on FreeBSD that could do similar - others may, or search the ports for NTFS related software and see what the pkg-descr files say. --Alex PS A question is only dumb if you ask the same one repeatedly. This question might demonstrate some ignorance, but we were all ignorant once and questions are one of the best cures! IMHO, of course. (In the computer world, manuals are another cure but the page for dump was written when UFS was the *only* filesystem that worked on BSD, so fails to actually answer your question). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump and :
[EMAIL PROTECTED] writes: > On Wed, Feb 18, 2004 at 09:20:32AM -0500, Lowell Gilbert wrote: > > [EMAIL PROTECTED] writes: > > I haven't tried this, but from looking at the man page, I might expect > > > > dump -f /path/to/dump/dir/some\:file > > > > to work... > > Sorry no, this way the colon is just escaped in the shell. True; I was just being careful there. I was hoping that the colon might be ignored if a slash had come first, on the theory that a slash would be illegal in the remote syntax anyway. It wouldn't be terribly hard to put such a check in; is it worth the effort? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump and :
On Wed, Feb 18, 2004 at 09:20:32AM -0500, Lowell Gilbert wrote: > [EMAIL PROTECTED] writes: > > > just stumbled over this. If I try to do a dump to a file which has a ':' > > in its name or path, dump tries to connect to a server (which is > > obvious as this is the notation for a remote dump). > > Precisely. > > > example: > > # dump -f some:file /var > > DUMP: rcmd: getaddrinfo: hostname nor servname provided, or not known > > DUMP: login to some as root failed. > > > > escaping (dump -f "some\:file" /var) does not work. > > Right; it's not the shell that you need to hide the colon from, so > escaping it in the shell syntax won't make any difference. That's why I put the " aroud the name (trying to escape the colon to dump) > > > Is this behaviour > > intended? > > Yes; as you pointed out yourself, it's the notation for remote host > access. > > > Is there a workaround? (besides making a symlink w/o the : in > > the name or using another filename/path) > > I haven't tried this, but from looking at the man page, I might expect > > dump -f /path/to/dump/dir/some\:file > > to work... Sorry no, this way the colon is just escaped in the shell. > > -- > Lowell Gilbert, embedded/networking software engineer, Boston area: > resume/CV at http://be-well.ilk.org:8088/~lowell/resume/ > username/password "public" thanks anyway Ste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump and :
[EMAIL PROTECTED] writes: > just stumbled over this. If I try to do a dump to a file which has a ':' > in its name or path, dump tries to connect to a server (which is > obvious as this is the notation for a remote dump). Precisely. > example: > # dump -f some:file /var > DUMP: rcmd: getaddrinfo: hostname nor servname provided, or not known > DUMP: login to some as root failed. > > escaping (dump -f "some\:file" /var) does not work. Right; it's not the shell that you need to hide the colon from, so escaping it in the shell syntax won't make any difference. > Is this behaviour > intended? Yes; as you pointed out yourself, it's the notation for remote host access. > Is there a workaround? (besides making a symlink w/o the : in > the name or using another filename/path) I haven't tried this, but from looking at the man page, I might expect dump -f /path/to/dump/dir/some\:file to work... -- Lowell Gilbert, embedded/networking software engineer, Boston area: resume/CV at http://be-well.ilk.org:8088/~lowell/resume/ username/password "public" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dump and nodump flag?
Ok... (whacking forehead)duh. got focused on mode and stopped reading flags. Thanks for the kick start :) Still wonders if this is the best way to accomplish the goal of only backing up a partial filesystem? Peace, Blake Drew Tomlinson wrote: - Original Message - From: "Blake Swensen" <[EMAIL PROTECTED]> To: "FreeBSD List" <[EMAIL PROTECTED]> Sent: Thursday, November 07, 2002 9:59 AM Subject: Dump and nodump flag? The manual for dump states: ... -h level Honor the user ``nodump'' flag (UF_NODUMP) only for dumps at or above the given level. The default honor level is 1, so that incremental backups omit such files but full backups retain them. ... I have looked at the several man pages referenced by this, and searched the mailing list archives. I want to take advantage of this feature but cannot find how to set this flag. This is really an attempt to only back up part of a file system on a dump run. For instance, /dev/ad2s1e is mounted at /usr/exports/corporate and contains /usr/exports/corporate/reallyimportant and /usr/exports/corporate/justjunk. I really don't care to back up justjunk, but since both justjunk and reallyimportant are in the same filesystem I really cannot do: dump . /user/exports/corporate/reallyimportant. Was thinking that the nodump flag might be the answer... if I could find out how to set it, and if nobody else has a better idea. This and other flags are set via the 'chflags' utility. Check the man page. Cheers, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: Dump and nodump flag?
- Original Message - From: "Blake Swensen" <[EMAIL PROTECTED]> To: "FreeBSD List" <[EMAIL PROTECTED]> Sent: Thursday, November 07, 2002 9:59 AM Subject: Dump and nodump flag? > The manual for dump states: > > ... > -h level > Honor the user ``nodump'' flag (UF_NODUMP) only for dumps at or > above the given level. The default honor level is 1, so that > incremental backups omit such files but full backups retain them. > ... > > I have looked at the several man pages referenced by this, and searched > the mailing list archives. I want to take advantage of this feature but > cannot find how to set this flag. > > This is really an attempt to only back up part of a file system on a > dump run. For instance, /dev/ad2s1e is mounted at > /usr/exports/corporate and contains > /usr/exports/corporate/reallyimportant and /usr/exports/corporate/justjunk. > > I really don't care to back up justjunk, but since both justjunk and > reallyimportant are in the same filesystem I really cannot do: > dump . /user/exports/corporate/reallyimportant. > > Was thinking that the nodump flag might be the answer... if I could find > out how to set it, and if nobody else has a better idea. This and other flags are set via the 'chflags' utility. Check the man page. Cheers, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
