Ray,
This is now fixed in master (248f192).
It was getting too aggressive stripping common portions of the remote
directory path off, and it was empty (instead of "/") in the case you
mentioned, causing the restore to the home directory, not /.
Craig
On Mon, Apr 24, 2017 at 9:20 AM, Ray Frush <[email protected]> wrote:
> I’ve been away from BackupPC for a few years, and have just installed
> 4.1.1 as a proposed solution in our environment. My previous experience
> has been with 3.x versions of BackupPC, which I’ve had great experiences
> with.
>
> My question/observation is this:
>
> In my Test Case, I deleted ‘/opt' from my Linux system that is being
> backed up by BackupPC.
>
> Pass 1:
> In my first attempt to restore ‘/opt’, I navigated to the most recent
> backup and selected the checkbox next to the folder “opt” and hit “Restore
> selected files”.
> The next screen, I kept the default host, share and dir (testserver, /,
> /) and hit “Start Restore”. The final confirmation screen showed:
>
> You are about to start a restore directly to the machine testserver. The
> following files will be restored to share /, from backup number 3:
> Original file/dir Will be restored to
> testserver://opt testserver://opt
>
> However, the files were restored into "testserver:/root/opt”. Not
> exactly what I was expecting. I did this test twice to be sure.
>
>
> Pass 2:
> In my next attempt, instead of selecting “/opt” from the top level of the
> restore screen, I navigated into the "/opt” directory which showed a list
> of all the files/directories in /opt, and then selected “Select all” and
> proceeded with the restore. Once again, I navigated through the next
> screen keeping the defaults, and the final confirmation screen again showed:
>
> You are about to start a restore directly to the machine testserver. The
> following files will be restored to share /, from backup number 3:
> Original file/dir Will be restored to
> testserver://opt testserver://opt/
>
> In this example, the files were flawlessly restored to the correct
> location, ’testserver:/opt’.
>
>
> I’m wondering if anyone else has observed this behavior, or can suggest
> what I might be doing incorrectly to get the unexpected result in my first
> test case. Otherwise it sounds like I may have hit a bug.
>
> Thanks.
>
> I’ve been away from BackupPC for a few years, and have just installed
> 4.1.1 as a proposed solution in our environment. My previous experience
> has been with 3.x versions of BackupPC, which I’ve had great experiences
> with.
>
> My question/observation is this:
>
> In my Test Case, I deleted ‘/opt' from my Linux system that is being
> backed up by BackupPC.
>
> Pass 1:
> In my first attempt to restore ‘/opt’, I navigated to the most recent
> backup and selected the checkbox next to the folder “opt” and hit “Restore
> selected files”.
> The next screen, I kept the default host, share and dir (testserver, /,
> /) and hit “Start Restore”. The final confirmation screen showed:
>
> You are about to start a restore directly to the machine testserver. The
> following files will be restored to share /, from backup number 3:
> Original file/dir Will be restored to
> testserver://opt testserver://opt
>
> However, the files were restored into "testserver:/root/opt”. Not
> exactly what I was expecting. I did this test twice to be sure.
>
>
> Pass 2:
> In my next attempt, instead of selecting “/opt” from the top level of the
> restore screen, I navigated into the "/opt” directory which showed a list
> of all the files/directories in /opt, and then selected “Select all” and
> proceeded with the restore. Once again, I navigated through the next
> screen keeping the defaults, and the final confirmation screen again showed:
>
> You are about to start a restore directly to the machine testserver. The
> following files will be restored to share /, from backup number 3:
> Original file/dir Will be restored to
> testserver://opt testserver://opt/
>
> In this example, the files were flawlessly restored to the correct
> location, ’testserver:/opt’.
>
>
> I’m wondering if anyone else has observed this behavior, or can suggest
> what I might be doing incorrectly to get the unexpected result in my first
> test case. Otherwise it sounds like I may have hit a bug.
>
> Thanks.
>
> --
> Ray Frush "Either you are part of the solution
> T:970.491.5527 <970.288.6223> or part of the precipitate."
> -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
> Colorado State University | IS | System Administrator
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> BackupPC-users mailing list
> [email protected]
> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki: http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
