Deleting backups with `find -mtime +n` – more backups remain than expected
This is my script:
find /backup/dir -mindepth 1 -depth -mtime +4 -exec rm -rf {} ;
And after this I have always not last 4 backups but 5.
I think find sucks for this. Maybe someone have any idea how to use other tool in this?
linux backup find
add a comment |
This is my script:
find /backup/dir -mindepth 1 -depth -mtime +4 -exec rm -rf {} ;
And after this I have always not last 4 backups but 5.
I think find sucks for this. Maybe someone have any idea how to use other tool in this?
linux backup find
Are the backups in separate directories under/backup/dir/
? While usingrm -r
anyway,-mindepth 1 -maxdepth 1
may be a more elegant approach (no need for-depth
then).
– Kamil Maciorowski
Dec 24 '18 at 13:19
add a comment |
This is my script:
find /backup/dir -mindepth 1 -depth -mtime +4 -exec rm -rf {} ;
And after this I have always not last 4 backups but 5.
I think find sucks for this. Maybe someone have any idea how to use other tool in this?
linux backup find
This is my script:
find /backup/dir -mindepth 1 -depth -mtime +4 -exec rm -rf {} ;
And after this I have always not last 4 backups but 5.
I think find sucks for this. Maybe someone have any idea how to use other tool in this?
linux backup find
linux backup find
edited Dec 24 '18 at 13:15
Kamil Maciorowski
25.8k155678
25.8k155678
asked Dec 24 '18 at 10:41
rkarpinskirkarpinski
11
11
Are the backups in separate directories under/backup/dir/
? While usingrm -r
anyway,-mindepth 1 -maxdepth 1
may be a more elegant approach (no need for-depth
then).
– Kamil Maciorowski
Dec 24 '18 at 13:19
add a comment |
Are the backups in separate directories under/backup/dir/
? While usingrm -r
anyway,-mindepth 1 -maxdepth 1
may be a more elegant approach (no need for-depth
then).
– Kamil Maciorowski
Dec 24 '18 at 13:19
Are the backups in separate directories under
/backup/dir/
? While using rm -r
anyway, -mindepth 1 -maxdepth 1
may be a more elegant approach (no need for -depth
then).– Kamil Maciorowski
Dec 24 '18 at 13:19
Are the backups in separate directories under
/backup/dir/
? While using rm -r
anyway, -mindepth 1 -maxdepth 1
may be a more elegant approach (no need for -depth
then).– Kamil Maciorowski
Dec 24 '18 at 13:19
add a comment |
1 Answer
1
active
oldest
votes
I think find sucks for this. Maybe someone have any idea how to use other tool in this?
find
may still be the right tool.
From man find
:
-mtime n
File's data was last modifiedn*24
hours ago. See the comments for-atime
to understand how rounding affects the interpretation of file modification times.
[…]
Numeric arguments can be specified as
+n
for greater thann
,
[…]
The relevant comment is
When
find
figures out how many 24-hour periods ago the file was last accessed, any fractional part is ignored, so to match-atime +1
, a file has to have been accessed at least two days ago.
This means 0
is possible. With -mtime +4
backups that report 0
, 1
, 2
, 3
or 4
are left intact. I assume your backups are daily so each of the mentioned numbers is reported exactly once. Five numbers, five backups don't pass the test, five backups remain.
If you use -mtime +3
instead of -mtime +4
then backups that report 0
, 1
, 2
or 3
will remain; probably four backups total, the number you wanted.
See also Why does the behaviour of find
differ using -mtime -0
vs. +0
?
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1387356%2fdeleting-backups-with-find-mtime-n-more-backups-remain-than-expected%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I think find sucks for this. Maybe someone have any idea how to use other tool in this?
find
may still be the right tool.
From man find
:
-mtime n
File's data was last modifiedn*24
hours ago. See the comments for-atime
to understand how rounding affects the interpretation of file modification times.
[…]
Numeric arguments can be specified as
+n
for greater thann
,
[…]
The relevant comment is
When
find
figures out how many 24-hour periods ago the file was last accessed, any fractional part is ignored, so to match-atime +1
, a file has to have been accessed at least two days ago.
This means 0
is possible. With -mtime +4
backups that report 0
, 1
, 2
, 3
or 4
are left intact. I assume your backups are daily so each of the mentioned numbers is reported exactly once. Five numbers, five backups don't pass the test, five backups remain.
If you use -mtime +3
instead of -mtime +4
then backups that report 0
, 1
, 2
or 3
will remain; probably four backups total, the number you wanted.
See also Why does the behaviour of find
differ using -mtime -0
vs. +0
?
add a comment |
I think find sucks for this. Maybe someone have any idea how to use other tool in this?
find
may still be the right tool.
From man find
:
-mtime n
File's data was last modifiedn*24
hours ago. See the comments for-atime
to understand how rounding affects the interpretation of file modification times.
[…]
Numeric arguments can be specified as
+n
for greater thann
,
[…]
The relevant comment is
When
find
figures out how many 24-hour periods ago the file was last accessed, any fractional part is ignored, so to match-atime +1
, a file has to have been accessed at least two days ago.
This means 0
is possible. With -mtime +4
backups that report 0
, 1
, 2
, 3
or 4
are left intact. I assume your backups are daily so each of the mentioned numbers is reported exactly once. Five numbers, five backups don't pass the test, five backups remain.
If you use -mtime +3
instead of -mtime +4
then backups that report 0
, 1
, 2
or 3
will remain; probably four backups total, the number you wanted.
See also Why does the behaviour of find
differ using -mtime -0
vs. +0
?
add a comment |
I think find sucks for this. Maybe someone have any idea how to use other tool in this?
find
may still be the right tool.
From man find
:
-mtime n
File's data was last modifiedn*24
hours ago. See the comments for-atime
to understand how rounding affects the interpretation of file modification times.
[…]
Numeric arguments can be specified as
+n
for greater thann
,
[…]
The relevant comment is
When
find
figures out how many 24-hour periods ago the file was last accessed, any fractional part is ignored, so to match-atime +1
, a file has to have been accessed at least two days ago.
This means 0
is possible. With -mtime +4
backups that report 0
, 1
, 2
, 3
or 4
are left intact. I assume your backups are daily so each of the mentioned numbers is reported exactly once. Five numbers, five backups don't pass the test, five backups remain.
If you use -mtime +3
instead of -mtime +4
then backups that report 0
, 1
, 2
or 3
will remain; probably four backups total, the number you wanted.
See also Why does the behaviour of find
differ using -mtime -0
vs. +0
?
I think find sucks for this. Maybe someone have any idea how to use other tool in this?
find
may still be the right tool.
From man find
:
-mtime n
File's data was last modifiedn*24
hours ago. See the comments for-atime
to understand how rounding affects the interpretation of file modification times.
[…]
Numeric arguments can be specified as
+n
for greater thann
,
[…]
The relevant comment is
When
find
figures out how many 24-hour periods ago the file was last accessed, any fractional part is ignored, so to match-atime +1
, a file has to have been accessed at least two days ago.
This means 0
is possible. With -mtime +4
backups that report 0
, 1
, 2
, 3
or 4
are left intact. I assume your backups are daily so each of the mentioned numbers is reported exactly once. Five numbers, five backups don't pass the test, five backups remain.
If you use -mtime +3
instead of -mtime +4
then backups that report 0
, 1
, 2
or 3
will remain; probably four backups total, the number you wanted.
See also Why does the behaviour of find
differ using -mtime -0
vs. +0
?
edited Dec 24 '18 at 12:59
answered Dec 24 '18 at 11:04
Kamil MaciorowskiKamil Maciorowski
25.8k155678
25.8k155678
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1387356%2fdeleting-backups-with-find-mtime-n-more-backups-remain-than-expected%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Are the backups in separate directories under
/backup/dir/
? While usingrm -r
anyway,-mindepth 1 -maxdepth 1
may be a more elegant approach (no need for-depth
then).– Kamil Maciorowski
Dec 24 '18 at 13:19