Project

General

Profile

Actions

Bug #2395

closed

Fix Backup Strategy -- delete extra backups from time to time

Added by Michael Lee about 18 years ago. Updated over 17 years ago.

Status:
Resolved
Priority:
Immediate
Assignee:
Category:
misc
Target version:
Start date:
04/05/2006
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
2395

Description

Our current backup strategy is to backup the database every night (which is good). However, we don't delete any old backups, so we will inevitably run out of space. This needs to be fixed. We certainly don't need backups for EACH day the database has existed, but having some older copies might not be horrible either. I propose:

Keep all the backups for the last month.
Keep one weekly backup (or every 10 days, whatever is easier) from one month ago to 6 months ago.
Keep one monthly backup for anything older than 6 months.

In addition, we need to make sure that this backup is not just to VegBank- a copy needs to be distributed, either by email or network to an alternate machine. I don't know the current status of that "other-machine/off-site" backup, but it would be nice to know. PMark?


Related issues

Blocked by VegBank - Bug #2481: Fix Backup Strategy: where backups goResolvedChad Berkley06/28/2006

Actions
Actions #1

Updated by Michael Lee about 18 years ago

I just deleted backups from September 2005 and previous, keeping one per month in a new dir: /usr/vegbank/backup/oldarchive

This created 9GB free space.

Actions #2

Updated by P. Anderson about 18 years ago

Just off the top of my head, the simplest (but not best) approach would be to remove files after X days. This crontab line sets X=180.

10 2 * * * find /usr/vegbank/backup -name "*.bz2" -mtime +180 -maxdepth 1 -exec rm \{} \;

Actions #3

Updated by Michael Lee about 18 years ago

(In reply to comment #2)

Just off the top of my head, the simplest (but not best) approach would be to
remove files after X days. This crontab line sets X=180.

10 2 * * * find /usr/vegbank/backup -name "*.bz2" -mtime +180 -maxdepth 1 -exec
rm \{} \;

This doesn't solve the issue of keeping old backups (one per month). Also, if our system time gets off for some reason, this script could kill all our backups. Not sure what to do about that latter issue, as any approach likely would cause problems if the system time got off. Might be nice to somehow check that not all the backups are being deleted before deleting some? Just throwing ideas out...

Actions #4

Updated by Michael Lee about 18 years ago

Suggestion from Matt on conference call 06-APR-2006:

We need to copy the backups to a place on our hard drive, as we now do, which will be backups if we need them before tape backups are performed. Also, we need to copy the files to a machine that is tape-backedup. Older backups can then be deleted, because they are on tape.

*IMPORTANT* We also have items NOT in CVS that are large binary files that should be backed up when they are changed. These items are located in:
/usr/www/vegbank/htdocs/noncvs
on vegbank

Actions #5

Updated by Chad Berkley almost 18 years ago

Colby needs to be the one to do this.

Actions #6

Updated by Michael Lee almost 18 years ago

This bug has been split. This portion of the bug now deals only with removing extra old backups in the /usr/vegbank/backup dir of VegBank. They never get deleted, thus eventually we'll run out of space, see other comments for details.

Actions #7

Updated by Chad Berkley over 17 years ago

the backup script now keeps 5 backups (from the last 5 days) around but deletes older ones so that the disk does not get filled up. We should also have this directory backed up to tape at least once every 5 days to make sure we have an archive.

Actions #8

Updated by Redmine Admin about 11 years ago

Original Bugzilla ID was 2395

Actions

Also available in: Atom PDF