Edgewall Software
Modify

Opened 9 years ago

Closed 7 years ago

Last modified 11 months ago

#3198 closed enhancement (fixed)

Backuping environment: hotcopy to work over existing hotcopy

Reported by: iny+dev@… Owned by: cboos
Priority: normal Milestone: 0.11
Component: admin/console Version: 0.10-stable
Severity: normal Keywords: consider, backup
Cc:
Release Notes:
API Changes:

Description

# trac-admin /var/lib/trac hotcopy /var/lib/trac-backup
Hotcopying /var/lib/trac to /var/lib/trac-backup ... Hotcopy done.

# trac-admin /var/lib/trac hotcopy /var/lib/trac-backup
Command failed: [Errno 17] File exists: '/var/lib/trac-backup'
Hotcopying /var/lib/trac to /var/lib/trac-backup ...

It should just update the existing hotcopy properly.

Additionally it should be possible to make hotcopy silent, if there is no error. Getting such messages from cron is annoying.

Attachments (0)

Change History (16)

comment:1 Changed 9 years ago by mgood

  • Resolution set to wontfix
  • Status changed from new to closed

This cannot be done in an atomic operation, so if something fails in the middle of the hotcopy it will leave you with a broken hotcopy and no previous good version. You're better off moving the previous hotcopy to a temp location, make a new hotcopy, then remove the temp location once the hotcopy has completed successfully.

Backupninja includes scripts for doing this easily for your Trac and SVN backups.

comment:2 Changed 9 years ago by anonymous

I just wonder why people try so hard to make software hard to use…

comment:3 Changed 9 years ago by eblot

You would prefer that when the user starts a hotcopy, the previous hotcopy is destroyed ?

It's not about making software hard to use, it's about preventing from losing data if case of a user mistake or a software failure.

It's easy to wrap the hotcopy in a script that move the previous hotcopy out of the way before it starts a new backup. It is not to recover from overwritten data ;-)

comment:4 Changed 8 years ago by Noah Slater

Could the trac-admin not do this simple task for the user? Isn't software meant to do these tasks for us? As developers we should be thinking hard so our users don't have to.

comment:5 Changed 8 years ago by radek

  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from 0.9.5 to 0.10.3

""" You're better off moving the previous hotcopy to a temp location, make a new hotcopy, then remove the temp location once the hotcopy has completed successfully. """

I propose to add this suggested functionality to the hotcopy command, so the command could be called:

trac-admin /trac hotcopy /trac-backup /tmp

PS: Backupninja is not for Windows.

comment:6 Changed 8 years ago by cboos

  • Milestone set to 0.10.4

What about simply doing this:

  1. check if that <backup> folder already exists
  2. if yes, move the <backup> folder to <backup>.old
  3. if that fails, stop here (previous backup attempt that got interrupted? anyway, manual clean-up needed)
  4. do the hotcopy in <backup>
  5. remove <backup>.old. Although I'm always a bit uncomfortable when we add another usage of rmtree ;)

comment:7 Changed 8 years ago by radek

I would rather keep the original hotcopy functionality and add extended one as well. The steps could be:

Current functionality remains in case we call (ie. it gives error in case of existing backup dir):

trac-admin <trac dir> hotcopy <backup dir>

Extended functionality in case:

trac-admin <trac dir> hotcopy <backup dir> <tmpdir>

with these steps:

  1. check if that <backup dir> already exists
  1. if yes, move the <backup dir> folder under <tmpdir> (forcing overwrite )
  1. if that fails, stop here (previous backup attempt that got interrupted? anyway, manual clean-up needed)
  1. do the hotcopy in <backup>
  1. remove <backup dir> from <tmpdir>.

I believe, that this is better approach as you do not need to have write permission into the parent dir of <trac dir> as it is in case of tracproject.old approach. Of cource I assume write permissions to the declared <tmpdir>.

comment:8 Changed 8 years ago by eblot

I'm really -1 on this feature: let Trac does what it is meant for, and use your own scripts to customize your back up sequence the way you want.

Moving an existing back up copy is not a Trac task. It's an admin task.

Keep it simple. Unix tools are powerful because they are designed to do a precise task, and to do it well. They are a lot of free tools available that can manage archive rotation. There's no need to push this kind of task in Trac.

comment:9 follow-up: Changed 8 years ago by radek

Eblot, I understand your opinion. I also believe this should not do the task of other tools.

The requested approach is plotted only to allow overwrite. It should not expand to backup rotation etc.

Overwrite is important for some back up tools for incremental backup.

(And I am sorry in point 2 it should say copy instead of move).

comment:10 in reply to: ↑ 9 Changed 8 years ago by eblot

Replying to radek:

The requested approach is plotted only to allow overwrite. It should not expand to backup rotation etc.

Moving/renaming file is a kind of basic rotation.
Why not doing this from the calling script?

trac-admin hotcopy tmpdir && mv tmpdir backupdir

the same action could be achieved from an awful batch script w/ Windows: hotcopy in a temp dir; if the back up has been successfully created, rename the temp directory as the previous directory.

I'm not sure to understand the need to re-implement this feature in trac-admin (?)

comment:11 Changed 8 years ago by cboos

  • Keywords consider added
  • Milestone changed from 0.10.5 to 1.0

comment:12 Changed 7 years ago by dvska

  • Keywords backup added
  • Summary changed from hotcopy to work over existing hotcopy to Backuping environment: hotcopy to work over existing hotcopy
  • Version changed from 0.10.3 to 0.10-stable

Windows users, you can schedule such shell command:

c:\python25\scripts\trac-admin E:\somepath\Trac_env hotcopy s:\Trac_env_Backups\%date%

comment:13 Changed 7 years ago by cboos

  • Milestone changed from 1.0 to 0.11
  • Owner changed from daniel to cboos
  • Status changed from reopened to new

I side with eblot here, as doing a backup really depends on some outside strategy, and being able to overwrite an existing backup by default can't really be considered as safe…

However, the current behavior is not really satisfying, as we're failing with an internal error.

comment:14 Changed 7 years ago by cboos

  • Resolution set to fixed
  • Status changed from new to closed

I fixed the hotcopy in r6486, so that a nicer error message is produce and we make sure that an error exit code is still given back to the shell, so that an alternative action can still be taken by a backup script.

comment:15 Changed 5 years ago by anonymous

Currently implementing a backup for trac on astf 1 to 3. It will perform a trac-admin hotcopy, then scp it to a directory on astf-1 to be picked up by simple-backup.sh

comment:16 Changed 3 years ago by anonymous

Would be nice if trac-admin allowed a hotcopy into an existing, empty directory. (rsnapshot calls backup scripts with the working directory set to a new empty directory to place the backup in. Now with trac-admin, I need to create an extra subdirectory.) This would be more in line with svnadmin hotcopy as well.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain cboos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from cboos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.