Re: backup script changes permissions
On Sun, Apr 06, 2008 at 11:00:53AM -0400, Haines Brown wrote: Osamu Aoki [EMAIL PROTECTED] writes: On Sun, Apr 06, 2008 at 07:28:51AM -0400, Haines Brown wrote: I'be brought up my backup script for discussion before, and folks where helpful in solving a problem, but the solution created another. I did not read it... In brief, I was directing stdout and stderr to: 21, and this by default creates a message, and when the message size limit was reached, it stopped the process. What I have is a script in ~/scripts that is known to my private cron db: ~/cron-brownh, which in turn is known to /etc/cron.weekly. find / -print | egrep -v ^/media|^/proc|^/sys|^/mnt | cpio -pdmuv /media/mirror/$dirName 21 | cat -vt I do not understand first First ? Just one that I can see. Or do you mean in the first script? My answer: I forget. In any case, it worked fine when run directly by root (sudo). Interesting and strange to me. Here's the new script which only sends an error message: find / -print | egrep -v ^/media|^/proc|^/sys | cpio -pdmuv /media/mirror/$dirName 21 | cat -vT /home/brownh/.backup.log However, it seems to convert ownership of all files backed up to brownh:brownh. From what account did you run this/ * root from real root * root from sudo * account brownh If last, files are owned by brownh. That is how it sould be. Well, I really don't know ;-(. I merged my private cron-brownh database, and so it would be run by cron, which is owned by root. In my ~/cron-brownh (owned by brownh:brownh) is the line: 0 4 * * 0 /home/brownh/scripts/backup So it is normal usser process by brownh. So change of owner is expected. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: backup script changes permissions
On Sun, Apr 06, 2008 at 10:42:19AM -0400, Haines Brown wrote: Kevin Mark [EMAIL PROTECTED] writes: On Sun, Apr 06, 2008 at 07:28:51AM -0400, Haines Brown wrote: I'be brought up my backup script for discussion before, and folks where helpful in solving a problem, but the solution created another. Now all files backed up have their ownerships changed to me, brownh:brownh. I did: cpio --help and the only thing that stuck out was this option: --no-preserve-ownerDo not change the ownership of the files so maybe add this and use: cpio -pdmuv --no-preserve-owner I'll give that a try. The logic of the option escaped me. It says, leave [files] owned by the user extracting them. This is the default of non-root users. In the past, if I ran my backup script as root (sudo), I didn't have ownership change, and when cron ran it there was no change either, although I did have other problems, which is why I messed with the script. It had been running for years without any problem, until I upgraded to etch. I assume the user here is cron, but then does not this option say leave the files owned by cron? Made no sense to me. Didn't sound like it was something I wanted to do. cron can be either user as you mentioned or from root (/etc/rc2.d/S89cron). anyway, you should run it under root to access all the files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: backup script changes permissions
On Sun, Apr 06, 2008 at 07:28:51AM -0400, Haines Brown wrote: I'be brought up my backup script for discussion before, and folks where helpful in solving a problem, but the solution created another. Now all files backed up have their ownerships changed to me, brownh:brownh. Here's the old script, which had the problem that output was going to a mail message that quickly exceeded system limits, and then caused the backup process to terminate: find / -print | egrep -v ^/media|^/proc|^/sys|^/mnt | cpio -pdmuv /media/mirror/$dirName 21 | cat -vt Here's the new script which only sends an error message: find / -print | egrep -v ^/media|^/proc|^/sys | cpio -pdmuv /media/mirror/$dirName 21 | cat -vT /home/brownh/.backup.log However, it seems to convert ownership of all files backed up to brownh:brownh. -- I did: cpio --help and the only thing that stuck out was this option: --no-preserve-ownerDo not change the ownership of the files so maybe add this and use: cpio -pdmuv --no-preserve-owner hth, K -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: backup script changes permissions
On Sun, Apr 06, 2008 at 07:28:51AM -0400, Haines Brown wrote: I'be brought up my backup script for discussion before, and folks where helpful in solving a problem, but the solution created another. I did not read it... Now all files backed up have their ownerships changed to me, brownh:brownh. Here's the old script, which had the problem that output was going to a mail message that quickly exceeded system limits, and then caused the backup process to terminate: Is this cron script? Why mail? find / -print | egrep -v ^/media|^/proc|^/sys|^/mnt | cpio -pdmuv /media/mirror/$dirName 21 | cat -vt I do not understand first Here's the new script which only sends an error message: find / -print | egrep -v ^/media|^/proc|^/sys | cpio -pdmuv /media/mirror/$dirName 21 | cat -vT /home/brownh/.backup.log However, it seems to convert ownership of all files backed up to brownh:brownh. From what account did you run this/ * root from real root * root from sudo * account brownh If last, files are owned by brownh. That is how it sould be. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: backup script changes permissions
On Sun, Apr 06, 2008 at 07:28:51AM -0400, Haines Brown wrote: I'be brought up my backup script for discussion before, and folks where helpful in solving a problem, but the solution created another. Now all files backed up have their ownerships changed to me, brownh:brownh. Why don't you use a prebuilt package such as backup2l? -- Noah Slater http://bytesexual.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: backup script changes permissions
Kevin Mark [EMAIL PROTECTED] writes: On Sun, Apr 06, 2008 at 07:28:51AM -0400, Haines Brown wrote: I'be brought up my backup script for discussion before, and folks where helpful in solving a problem, but the solution created another. Now all files backed up have their ownerships changed to me, brownh:brownh. I did: cpio --help and the only thing that stuck out was this option: --no-preserve-ownerDo not change the ownership of the files so maybe add this and use: cpio -pdmuv --no-preserve-owner I'll give that a try. The logic of the option escaped me. It says, leave [files] owned by the user extracting them. This is the default of non-root users. In the past, if I ran my backup script as root (sudo), I didn't have ownership change, and when cron ran it there was no change either, although I did have other problems, which is why I messed with the script. It had been running for years without any problem, until I upgraded to etch. I assume the user here is cron, but then does not this option say leave the files owned by cron? Made no sense to me. Didn't sound like it was something I wanted to do. -- Haines Brown, KB1GRM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: backup script changes permissions
Osamu Aoki [EMAIL PROTECTED] writes: On Sun, Apr 06, 2008 at 07:28:51AM -0400, Haines Brown wrote: I'be brought up my backup script for discussion before, and folks where helpful in solving a problem, but the solution created another. I did not read it... In brief, I was directing stdout and stderr to: 21, and this by default creates a message, and when the message size limit was reached, it stopped the process. What I have is a script in ~/scripts that is known to my private cron db: ~/cron-brownh, which in turn is known to /etc/cron.weekly. find / -print | egrep -v ^/media|^/proc|^/sys|^/mnt | cpio -pdmuv /media/mirror/$dirName 21 | cat -vt I do not understand first First ? Just one that I can see. Or do you mean in the first script? My answer: I forget. In any case, it worked fine when run directly by root (sudo). Here's the new script which only sends an error message: find / -print | egrep -v ^/media|^/proc|^/sys | cpio -pdmuv /media/mirror/$dirName 21 | cat -vT /home/brownh/.backup.log However, it seems to convert ownership of all files backed up to brownh:brownh. From what account did you run this/ * root from real root * root from sudo * account brownh If last, files are owned by brownh. That is how it sould be. Well, I really don't know ;-(. I merged my private cron-brownh database, and so it would be run by cron, which is owned by root. In my ~/cron-brownh (owned by brownh:brownh) is the line: 0 4 * * 0 /home/brownh/scripts/backup -- Haines Brown, KB1GRM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: backup script changes permissions
Noah Slater [EMAIL PROTECTED] writes: Why don't you use a prebuilt package such as backup2l? Noah, I might just do that. I've spent a lot of time struggling with the backup script, which only offered the advantage of having unarchived files, but in recent years I've not found it as necessary to recover single files as I used to, and doing so does not seem at all difficult with backup2l. I'm giving it a look. -- Haines Brown, KB1GRM -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: backup script changes permissions
On 07/04/2008, Haines Brown [EMAIL PROTECTED] wrote:
Noah Slater [EMAIL PROTECTED] writes:
Why don't you use a prebuilt package such as backup2l?
Noah, I might just do that. I've spent a lot of time struggling with the
backup script, which only offered the advantage of having unarchived
files,
but in recent years I've not found it as necessary to recover single
files as I used to, and doing so does not seem at all difficult with
backup2l. I'm giving it a look.
--
Haines Brown, KB1GRM
Hey,
There are other options around too such as local rsync. Something like
this should work similarly:
rsync -avh --exclude=/media --exclude=/proc --exclude=/sys /
/media/mirror/${dirName}/ 21 | cat -vT /home/brownh/.backup.log
cheers,
Owen.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
[EMAIL PROTECTED]
