bugJBackpack - Bugs: bug #31553, JBackback thinks it needs write...

 
 

bug #31553: JBackback thinks it needs write access on backup target even for restoring

Submitter:  D. Kriesel <opp>
Submitted:  Fri 05 Nov 2010 08:41:37 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Ready For Test
Privacy:  Public Assigned to:  ronnystandtke
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 18 Jun 2011 05:20:34 PM UTC, comment #5: 

Sorry for the late response...
The temporary database feature was released with version 0.9.1. Can you please test it and give some feedback?

Ronny Standtke <ronnystandtke>
Group administrator
Fri 14 Jan 2011 01:30:10 PM UTC, comment #4: 

I just committed support for temporary backup databases to svn. Please test.

Ronny Standtke <ronnystandtke>
Group administrator
Fri 14 Jan 2011 11:26:16 AM UTC, comment #3: 

No, right now JBackpack checks if the backup target directory is writable.

A possible workaround for the reported situation could be to show a warning message that the backup target directory can not be written to when trying to build the jbackpack database and create the database in a temporary folder instead. What do you think?

Ronny Standtke <ronnystandtke>
Group administrator
Fri 14 Jan 2011 10:29:04 AM UTC, comment #2: 

In linux would it work for me to create a symlink to a writable directory for jbackpack before I start?  For example,

/rdiffs/rdiff-backup-data/
/ridffs/jbackpack/ --> /home/myuser/jbackpack-db/

Anonymous
Sun 09 Jan 2011 10:03:11 PM UTC, comment #1: 

JBackpack creates a database (embedded Apache Derby) for easy and fast access to information about increments, directories and files in the directory <backup target>/rdiff-backup-data/jbackpack/

Creating this database is a heavy task (it involves unpacking and parsing all rdiff-backup metadata files of the corresponding backup and inserting all parsed information into the embedded database).

Without this database the restore file chooser would be unusable because the (possibly) huge rdiff-backup metadata files would have to be parsed after every directory change. This can take up to several minutes. With the database filled, changing directories can be done almost instantly.

Therefore, JBackpack actually needs write access on backup targets.

If you have any idea how to improve this situation, please let me know.

Ronny Standtke <ronnystandtke>
Group administrator
Fri 05 Nov 2010 08:41:37 AM UTC, original submission:  

Hi guys,

As - I think - lots of other users I
  * use a scripted rdiff-backup for my servers
  * at the same time would like to use the nice GUI of JBackPack for restoring.

Many server administrators prevent all users except for one single backup user from writing to their RDiff repositories - So do I. Now, here's the problem: When adding the target repository to JBackback under another user (e.g. the normal root user) it complains that it can't write and doesn't accept the target.

Suggestion:
Make JBackPack complain when it eventually is instructed to write. So people could use your nice software as "backup explorer" and for restore processes, while at the same time use their own scripted RDiffs for backup.

Greetz,
David

D. Kriesel <opp>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ronnystandtke (Posted a comment)
  • -email is unavailable- added by opp (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-06-20 ronnystandtke Assigned toNone ronnystandtke
    2011-06-20 ronnystandtke StatusNone Ready For Test

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code