All of those operations will benefit from shutting down database service, but level of improvement will depend on type of operation and amount of activity that database service is performing at given moment. (so you have 23,000 machines or 230,000? you have said 23,0000 )
I would perform incremental backup at lowest activity time during a day, full backup, large object moves/deletes/audit-purges during lowest activity day in a week.
All of them, with database service running (don't you need connectivity to support production operations?).
Schedule fixed maintenance window (once a week) for limited amount of time, for cache refresh and other database integrity tests (orphans, stuck objects, etc.). For that you need to stop database service.
When database service is running, all operations should access database remotely, not database file system directly.
Sorry, 23,000 machine objects.
I'm thinking of shutting down during the Incremental backups (2100 local time), which should bring the backup window down to < 3 hours.
I'm not sure how, since the ObjectDirectory backup doesn't allow for before/after batch jobs.
Weekly maintenance is Fridays, 2100, so it's not very busy. Those activities are generally completed in <15 minutes, so I think that's ok.
Weekly backup is Sat, 0600, ending after 43 hours!!! That's the one that bothers me the most, along with orphan scans. Is there any way to automate an orphan scan? What other "database integrity tests" would make sense?
Since the clients will just miss one or two syncs, I'm really not too worried about them during the "service outage".
Beside client syncs, don't you have automated client deployments, multiple admins performing tasks, web helpdesk recovery operations, reporting,....?
Maintenance work with scripts using CleanupMachineGroup, CleanupUserGroup, RestoreMachines, RestoreUsers, GetCounts can all be automated.
Why is your full backup taking so long? Backup to local disk (SAN or else), it is faster. Then you can copy from local disk to wherever it needs to be. Same with incremental.
No automated client deployments--those are handled elsewhere. I'm the primary admin, noone else does much. Web Help desk is needed, but at only 14-15 per month, I'll take that risk. (They'll page ME if they have trouble anyway!)
Got everything automated that you mention.
Backup: I don't know why it takes so long. I'm going to try a local backup this weekend, as opposed to the LAN backup that's currently running, and see if the difference is the LAN connection. If LAN is fast enough, then I can robocopy the backup, and bring the service (or performance) back up sooner.
No automated client deployments--those are handled elsewhere.
Really? As far as I know, for encryption to start, EEPC client have to establish connection with database.
Sorry, I was thinking of client deployments.
Yes, you are correct, new clients won't begin encrypting until they've synced successfully. Newly built machines generally are brought up during the daytime, so an overnight stop of the service wouldn't generally impact them. In addition, new machines have little/no data on them, so I'm ok with delaying encryption by a few hours.