mainstoreBackup - Support: sr #109117, allways...


sr #109117: allways restores the entire path

Submitter:  None
Submitted:  Sun 14 Aug 2016 05:14:51 PM UTC
Category:  None Priority:  5 - Normal
Severity:  1 - Wish Status:  None
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup

Mon 15 Aug 2016 11:44:37 AM UTC, comment #1: 


you're right. The implementation of storeBackupRecover is quite simple.

I see to options (Please test with a simple test environment before using it in real live):

1. Restore like you've done. Then mv the restored directory (with it's content) to the place you want it to be. Then delete the remaining rest (normally only a path) via rm -r .
This is how I'm using storeBackupRecover normally.

2. Restore always to the exact path origin (backupDir from but rename the directory to restore before doing so (or delete it) so there is no confusion about overwritten files (option --overwrite) and you get a complete restore of that directory from the backup.

Maybe you need option --createSparseFiles.
Option --flat simple means not to create any subdirectories. This is probably not what you want.

Hope this helps.

Looking forward, Heinz-Josef ;-)

PS: Yes, it would be nice to have a third option to restore the directory to restore exactly to the place you specify. :-)

Heinz-Josef Claes <hjclaes>
Group administrator
Sun 14 Aug 2016 05:14:51 PM UTC, original submission:  


I'm sorry to bother again, but I'm working heavily with StoreBackup in the last few days and therefore encounter some ... hm, is it problems really?
There is something about the restore-path of that I either don't understand (which is not unlikely) or which could be handled in a different/better way.

First of all: Thanks for this backuptool, which saved my life today. Well, at least the last 2 weeks of work.

I'm backing up my entire /home at least once a day and yesterday evening I did something awful wrong in /home/myname/Documents/Project, but didn't realize until just an hour ago. So more than an entire day lies between the "OK" backup and the current state of work. So I want to recover from yesterdays backup to /home/myname/Documents/Project_old and do a manual merge from there.
Normally I would do this using just copy & paste in the filebrowser. However this folder contains a tone of subfolders and a lot of files (there is even a git repository in there), so I wanted to spare me the hassle of unziping everything by hand and wanted to use instead.
So I did:
cd /mnt/backups/.../Date/myname/Documents -r Project -t /home/myname/Documents/Project_old
And got a folder structure like:
Ups! A quick look to the documentation: Ah, thats what the --flat option is for!
Removed this folder-Structure and did the same thing with --flat again. Now my Project was in ~/Documents/Project_old, but the underlying folder structure was gone as well.
A lot of reading and some experiments later, I did not find a way to accomplish my goal of having everything that was under ~/Documents/Project now in ~/Documents/Project_old. either rebuilds the entire folder structure, or ignores all folders and puts everything in there flat.

So either I'm missing something, or an option like --ignoreUpperFolders would be nice.





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

Attach Files:

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 hjclaes (Posted a comment)

    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.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-6ae7.
    Corresponding source code