Reset from secondary backup location


Author
Message
jimholman
jimholman
New Member
New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)
Group: Forum Members
Posts: 14, Visits: 35
I am new to Reflect in the past few days. I set my primary & secondary image backup locations. I had over 10 successful full & incremental backups to my server. One night the server locked out. Reflect 7.2 wrote the image to the secondary location (local drive). GREAT feature. But w/ my server back up 7.2 continues to write increments to the secondary local location. How do I get 7.2 to return to writing increments to the primary server location? Delete or move existing files?
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)
Group: Forum Members
Posts: 7K, Visits: 51K
I haven't used that particular feature myself, but I thought that it always tries the primary destination first and then only starts working its way down the alternative locations list if the primary destination is unavailable -- as opposed to permanently failing over to an alternate location and sticking with it even when the primary becomes available again.  First, are you sure the primary destination is in fact writable, and this isn't a case of Reflect trying to write to it and failing, and only THEN falling back to the alternate location?  Check the job log to see if Reflect is in fact targeting the alternate location right from the start.  If that's what you find, then I'd choose to edit your definition file, click the "Alternative locations" link underneath the destination field, and make sure your destinations are ranked as you want them.  If on the other hand Reflect is still trying to write to the primary destination first and failing, you'll need to figure out why that is.

jimholman
jimholman
New Member
New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)
Group: Forum Members
Posts: 14, Visits: 35
Thanks v much for your prompt reply jphughan. Before posting I had copied a file from my 7.2 workstation to the primary 7.2 backup location. I thought that meant the folder was open to write. And it is on copy/paste but when I tried to do a save to the primary server location from inside MS Word, that failed on try one but worked on try 2? I have some gremlins in my server. Correct again on checking the logs. Here is from the most recent one:

Validating location: \\DELLSERVER\Documents\Backup\Images\Envy\Macrium\ - Invalid (Access is denied.)
Using Location: F:\Backup\ENVY\Macrium\

Thanks much. I think the Reflect is OK, as above seems to indicate it is trying to write to the primary location.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)
Group: Forum Members
Posts: 7K, Visits: 51K
Go to Edit Defaults > Network and make sure there's an entry for that share (and only one entry) and that it contains valid credentials for read/write access.  The share path would be just \\DELLSERVER\Documents even if you're storing backups deep into a subfolder.

Edited 11 February 2020 12:19 AM by jphughan
jimholman
jimholman
New Member
New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)
Group: Forum Members
Posts: 14, Visits: 35
jphughan - 11 February 2020 12:18 AM
Go to Edit Defaults > Network and make sure there's an entry for that share (and only one entry) and that it contains valid credentials for read/write access.  The share path would be just \\DELLSERVER\Documents even if you're storing backups deep into a subfolder.

Thanks again. I appreciate your efforts. I am the type that goes through the whole interface, so I had seen that. The text above that dialogue indicates that I shouldn't need to add anything here as the network connection is pre-established in the Windows environment. The fact that I successfully did something like a dozen nightly backups w/ this dialog blank is indicative of the text above the dialog box being correct. I added an entry w/ \\DELLSERVER\Documents & my password anyway. I don't see how that could hurt, I do see how it might help. Thanks.
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)
Group: Forum Members
Posts: 7K, Visits: 51K
I actually just covered a lot of this in another thread recently, but basically if you start a backup manually, then yes Reflect will use the network connections already open in your Windows user session, because a manually invoked backup runs in the user context of the user who invoked it, and therefore it will have access to your open network connections.  The Network area is there for situations where you might not have a persistent connection open to that share, and also to support scheduled backups.  Those by default run under the SYSTEM account and therefore would NOT have access to any network connections open in your user session, and since the local SYSTEM account also has no inherent network privileges of any kind, you need to provide suitable network credentials for Reflect to use when running scheduled backups that way.

Another use case where that capability can be handy is for security-conscious users.  Some users set up a network share for their backups, then give Reflect read/write credentials to that share, but they use a read-only account to establish the connection to that share within their own Windows user session.  That means that if they ever get malware/ransomware running on their system, it won't have the ability to piggyback onto that active network connection and delete or maliciously encrypt your backups, because you've only got a read-only connection open.  And realistically, that's all you typically need persistently anyway to cover scenarios where you might want to restore something.  But of course Reflect still needs the read/write credentials to create backups, and if YOU ever need read/write access, you can still disconnect the read-only connection and briefly reconnect to that share using read/write credentials.

The tricky part about the above design is that if you only have a read-only connection open and then you start a manual backup, then Reflect will also be limited to read-only access, which obviously won't work.  The reason is that Windows does not allow multiple connections to the same share within the same user context using different credentials.  So for people who want to implement the design I just described AND invoke backups manually without having any sort of schedule, one way to do that is to create a schedule with a one-time execution set to a date in the past. That won't trigger any scheduled backup of course, but it WILL create a Windows Scheduled Task, and those can be invoked manually -- and when they are, they run under the SYSTEM account, which means alternate credentials can be used.  The way you'd invoke that type of backup manually would be under the Scheduled Backups tab, not the Backup Definition Files tab.

Edited 11 February 2020 3:53 AM by jphughan
jimholman
jimholman
New Member
New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)
Group: Forum Members
Posts: 14, Visits: 35
jphughan, you are very patient & generous w/ your time. Also you are clearly very knowledgeable about Windows permissions/shares issues. AND, with your help & my stumbling we have uncovered a bug. Some data points:

1. My addition of the share & password done yesterday per your good help at  Edit Defaults > Network made no difference. Last night's increment was written to the secondary location on a local drive rather than the primary location on the server share.
2. You definitely pointed me in the right direction above. I manually started an increment backup just now by using the increment choice on the scheduled backups tab. Reflect yet again writes to the secondary path on the local drive.
3. Finally I went to the Backup Definitions Files tab & started a manual increment backup from there.  Bingo. Reflect correctly writes to the primary backup location on the server share when reading the XML file.

That has to be a bug. Remember, until I had the case of the server going down, I had an even dozen successful increments written by the Win task scheduler to the primary path pointing to the share on the server. Those successful increments all have 3:00 AM time stamps. If the increments worked fine before the server went temporarily offline, the software should be capable of returning to writing the increments via task scheduler, no?
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)
Group: Forum Members
Posts: 7K, Visits: 51K
Manually executing a job from the Scheduled Backups tab works differently from manually executing a job from the Backup Definition Files tab.  That is not a bug; it's just related to how Windows works.  The former calls a scheduled task (which if you don't have a schedule for your definition file won't even exist), which then starts Reflect in the background.  The latter runs the job within a Reflect instance that exists within the logged-on user's session.  And due to architecture and security model aspects of Windows, those two invocation methods can result in different behaviors.  I realize it's confusing and unintuitive to the end user because they just see a "Run Now" option in two different places that seem very similar, but they're not.

Anyhow, take a look at the log for a job you invoked via scheduled task.  Is it still showing an attempt to access the primary destination first followed by an authentication failure before resorting to the secondary?  If so, it means that the Network credentials aren't correct, or it could mean that the job isn't matching against that entry.  Make sure the share path as configured in the definition file and the Network authentication entry match, e.g. make sure you're not using \\MyServer\MyShare in one location and \\MyServerIPAddress\MyShare in another.  And definitely don't specify your destination as a mapped network drive letter; you want a proper UNC path, because mapped drives are also only valid within the context of the user session that created them.

I agree that if scheduled Incrementals worked before the server outage, then it's reasonable to expect they would continue to work after service has been restored.  However, I'm not entirely sure how your scheduled backups would have worked prior to the outage if you didn't have an entry in the Network area beforehand to provide credentials, unless either the server was allowing anonymous writes to that share (bad idea) or you previously had your scheduled backups configured to run under a real user account that had inherent permissions to the share instead of using the default SYSTEM account.  But since I also don't know anything about the outage or what might have been done to the server to bring it back up, I can't be sure that nothing was changed on the server that might be responsible for the different behavior.  Again, checking the log of a scheduled backup to see if Reflect even attempted to access the primary destination first will be useful information.  If it shows an authentication failure, then something is different on the server post-outage compared to pre-outage.  Maybe a password was changed, maybe the account you're trying to use is disabled or locked out?

Edited 11 February 2020 7:49 PM by jphughan
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)Macrium Evangelist (10K reputation)
Group: Forum Members
Posts: 7K, Visits: 51K
Just to make one additional point clear, I truly don't think this will boil down to, "Reflect always skips the primary destination entirely on scheduled backups even though it correctly goes there first when executed interactively."  The reason is that the destinations are specified solely in the job's XML definition file, and that same file is called to execute the job regardless of how the job is invoked.  You can even go into Windows Task Scheduler to see the command that gets run.  It calls Reflect and points to that XML file.  So unless you find that somehow your scheduled backup is calling a different XML file than you believed it was (which come to think of it did turn out to be the case once with another user I helped a while ago), then the XML definition file is NOT a variable between those two methods of running the backup job.  Authentication and permissions however are definitely variables.
jimholman
jimholman
New Member
New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)New Member (17 reputation)
Group: Forum Members
Posts: 14, Visits: 35
From log using scheduled task initiation:

Starting Image - Tuesday, February 11, 2020 11:41:53
Initializing
Validating location: \\DELLSERVER\Documents\Backup\Images\Envy\Macrium\ - Invalid (Access is denied.)
Using Location: F:\Backup\ENVY\Macrium\
Destination Drive: Samsung (FSmile - Free Space 51.63 GB
Free space threshold: Delete oldest backup sets when free space is less than 120.00 GB

From log using backup definition file:

Destination:
Backup Type: Incremental
File Name: Append to recent image in directory '\\DELLSERVER\Documents\Backup\Images\Envy\Macrium\'
Attempting to connect to: '\\DELLSERVER\Documents\Backup\Images\Envy\Macrium'
Successfully connected
\\DELLSERVER\Documents\Backup\Images\Envy\Macrium\86083A97DB306923-13-13.mrimg
Alternative location: F:\Backup\ENVY\Macrium\

Server path has always been specified as 
\\DELLSERVER\Documents
 Never used an IP address
I only know the server went down because when I looked at it the first time I saw that the increment was written to the local drive, the server screen was at the login asking for a password, so I assume something caused the server to reboot, but I don't know what. NOTHING was changed (passwords or any setting) on the server or the W10 workstation post server reboot.

Another data point. For now I have continued to run Win 7 file backup nightly via task scheduler. It writes to a folder just above the Macrium folder on the server \\DELLSERVER\Documents\Backup Works perfectly. Every night. For months. No user accounts have been changed. No lockouts.

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search