Backuping environment: hotcopy to work over existing hotcopy

[iny+dev@…]

# 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.

[mgood]

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.

[anonymous]

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

[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 ;-)

[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.

[radek]

""" 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.

[cboos]

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 ;)

[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

2. if yes, move the <backup dir> folder under <tmpdir> (forcing overwrite )

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 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>.

[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.

[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).

[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 (?)

[dvska]

Windows users, you can schedule such shell command:

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

[cboos]

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.

[cboos]

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.