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

 
 

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

Submitted by:  D. Kriesel <opp>
Submitted on:  Fri 05 Nov 2010 08:41:37 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Ready For Test
Privacy: PublicAssigned to: Ronny Standtke <ronnystandtke>
Open/Closed: Open

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 20 Jun 2011 11:09:37 AM UTCronnystandtkeAssigned toNone=>ronnystandtke
    Mon 20 Jun 2011 10:59:50 AM UTCronnystandtkeStatusNone=>Ready For Test

    Back to the top


    Powered by Savane 3.1-cleanup1