Guess I wouldn’t have tried it sitting in /. I probably would have created a
new empty directory …. and named it
/newvar. Then I’d be sitting in /newvar, and tried to restore /var.
And I would get
/newvar/var probably. Not necesarily.
But that’s okay, I know how to do THAT kind of fix.
And I usually am restoring things at a much lower level. Like
/var/one/two/three/four
so I’ve created a new empty “fourA” perhaps.
And I get /var/one/two/three/fourA/one/two/three/four
which I *still* know how to fix. I’m not really complaining. I’m just
saying that’s how it usually works out.
Nevermind — I was just empathizing with Gene. Not looking for a fix.
Deb
On May 7, 2015, at 3:17 PM, Jean-Louis Martineau <[email protected]> wrote:
> amrecover can remove everything in the directory you restore to, so it must
> not be /, it should always be an empty directory.
>
> Debra, what you say doesn't make sense, if the dle is /var then the /var path
> is not in the backup so it can't be restored.
>
> But if the dle is / with and include or './var' then a var directory will be
> created.
>
> Jean-Louis
>
> On 05/07/2015 04:00 PM, Debra S Baddorf wrote:
>> No, if you back up /var and are sitting ABOVE /var (i.e. in
>> / I suppose )
>> it’ll be okay. Otherwise, if you are sitting IN /var and you try to
>> restore /var
>> you’ll get /var/var
>>
>> Won’t you? That’s the kind of thing I always find.
>> Deb
>>
>>
>> On May 7, 2015, at 2:27 PM, Paul Yeatman <[email protected]> wrote:
>>
>>>
>>>
>>> On Thu, 2015-05-07 at 02:54 -0400, Gene Heskett wrote:
>>>> Got it, recovery done, but did have to move it all up one level to get it
>>>> in the right place.
>>> It should be in the right place if you are in the same directory as the
>>> one you are backing up. If you back up /var and are in /var when
>>> restoring, all data should be in the correct location once the restore
>>> is completed.
>>>
>>> Paul
>>>
>>
>
