Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Looking for files using -mtime flag - is my syntax suitable? 2

Status
Not open for further replies.

bazil2

Technical User
Feb 15, 2010
148
DE
(Elementary user)

I have SQL backup files that are saved every weekday to a specific path.

Before the tape backup executes, the following script is used to remove the backup from the previous day.

This is fine for Tuesday - Friday, however on Monday, if I have understood correctly, the -mtime flag needs to be +3 in order to delete Friday's backup from the previous week.

Here is my script:

find /my/path/SQL_Backups/ \( -name '*.bak' -o -name '*.txt' \) -mtime +1 -exec rm {} \;

Can anyone please help me in making this script applicable to all weekdays, i.e., a modification date '> 1'.

Best regards
 
Assuming the job runs from a crontab, set your '+1' to run Tue to Fri and have a '+3' that runs on Mondays only.



Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.
Webmaster Forum
 
Thank you very much; I see what you mean. The mtime flag +1 only means +1 and not >1

I'll take your advice!

Best regards
 
Uh, no.

[pre]
-mtime 3 == Exactly 3 days ago.
-mtime -3 == Less than 3 days ago.
-mtime +3 == More than 3 days ago.
[/pre]
Where a "day" is a 24 hour period from the moment you are running the command (doesn't necessarily coincide with the calendar day's start/end at midnight).

From the "man" page...

[pre]
Example 6 Selecting a File Using 24-hour Mode

The descriptions of -atime, -ctime, and -mtime use the ter-
minology n ``24-hour periods''. For example, a file accessed
at 23:59 is selected by:

example% find . -atime -1 -print

at 00:01 the next day (less than 24 hours later, not more
than one day ago). The midnight boundary between days has no
effect on the 24-hour calculation.
[/pre]



 
Many thanks, I really appreciate you explaining that!

Have a look at the following:

-rwxr--r-- 1 nobody nobody 1394176 Oct 17 18:00 ReportServerTempDB_backup_201410171800.bak

[root@sgi SQL_Backups]# find /my/path/SQL_Backups/ \( -name '*.bak' -o -name '*.txt' \) -mtime +3 -exec ls {} \;

This returns nothing. However ...

[root@sgi SQL_Backups]# find /my/path/SQL_Backups/ \( -name '*.bak' -o -name '*.txt' \) -mtime +2 -exec ls {} \;

This returns:

-rwxr--r-- 1 nobody nobody 2835968 Oct 17 18:00 /my/path/SQL_Backups/ReportServer_backup_201410171800.bak
-rwxr--r-- 1 nobody nobody 1394176 Oct 17 18:00 /my/path/SQL_Backups/ReportServerTempDB_backup_201410171800.bak

The time of executing this was October 20th @ 20:30

Is this the behaviour you would expect?

Best regards
 
Hmmm, not really. If I'm doing the time math correctly, "+3" 24 hour periods should include those files. They were created ((3 * 24) + 2.5) hours before the command was run.

Things that may affect that...
[ul]
[li]What version of Unix are you on? My man page and behaviour is from Solaris.[/li]
[li]Are you running this from a different time zone?[/li]
[/ul]

If it is rounding the day portion, then that behaviour do look as expected.

One additional thing, find has an option "[tt]-ls[/tt]" that does what your "[tt]-exec ls {} \;[/tt]" does. Much easier to type.


 
Many thanks for the tip!

I'm using RedHat 5.9

Best regards
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top