Iperius split backup files10/2/2023 ![]() ![]() but no one has access to the C: drive of the server besides the admin and that is me. I suppose I see the benefit as it pertains to if files were deleted, etc. This may sound very noobish because again backup is not my strong suit (in terms of theory and whatnot). I was somewhat questioning the need to backup everything on the C: drive because it is setup as a 6 Disk RAID 10, so there is already redundancy there. Those are legacy so if they are way off, please give me a break :) lol. The one thing that I did not change was the selections. I reconfigured everything, from the devices, to media, and created policies for the jobs. Looking back through the logs though, I see that this Full backup has always taken this long. I left it alone because I was not familiar with it and it seemed to work. I came into the setup that was initially on BE as I had mentioned. ![]() Herein lies a question that I had been thinking of the other day. It is essentially the whole C: drive and then our E: drive (which is all data store), System State and Shadow copy components. I have attached a screenshot for reference. What I am backing up may certainly be the problem, as this FULL backup is as it states, and entire FULL backup of all of the HD's on the server. Some points to mention: While this is surely a B2D over the network, I was getting nearly the same throughput when backing up the same data set over eSata to an external, so I am not thinking the network is the issue (thank goodness). For more information on installation as a service, see this tutorial.Thanks for the advice guys. With these configurations, even scheduled backups can run without errors, just like those run manually, as the user they run under will be the same (or will have the same privileges) as the user under which the backups are run manually. This account can be specified globally here in the service panel (it will be valid for all network paths), or else as a single destination, as shown in the figure below: installing the service with the local system account and selection of an account that will be impersonated by the backup processes:įinally, one may need to set up an additional account in order to access network paths, as, for example, in the case of a folder shared on a NAS drive and protected by a password. In this second image, we can see the other mode, i.e. Of course one can change the logon account of the service directly from among the Windows services (the Iperius Backup service is called “Iperius Backup Service”). In the image below, we can see the choice of a specific account (we always recommend using an administrator account) for installing the service: If one installs the service with a specific account, the AutoRun backup window will not be visible as it is running in a session other than the primary one. The difference between the two solutions is minimal (and the choice between the two is usually to be determined only in more specific situations), except for the fact that impersonating allows you to continue to see the AutoRun window of the backups in the primary session. The authentication issue has an easy solution since Iperius allows one to install the service using a specific account and to impersonate a certain user account for backup operations. In this case, let’s make sure we have entered the complete network path (example: Īs\backup) and not a mapped network drive. In fact, a Windows service cannot access mapped network drives, simply because they do not exist in the service session (but are automatically reconnected, and therefore created, only at user logon). In this case, scheduled backups, since they are run by the service, will also run using this user account, which generally does not have access to network paths, nor may it have the necessary privileges to access certain folders.Īnother possible cause is the use of mapped network drives instead of the full network path. When Iperius is installed as a Windows service and the default settings are left as they are, the service will be started using the local system account, or SYSTEM. The cause of this problem is very simple. These errors generally occur only when the backup is run in the automatic mode according to a schedule, while backups run manually complete successfully. A common problem that one can encounter when installing Iperius Backup as a service and setting up a schedule for it is to encounter errors accessing network paths. ![]()
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |