Automatic Backup of User Folders with Google Drive Sync
All Windows laptops and desktop assigned on a 1:1 basis to employees and students at Charles E. Smith Jewish Day School were automatically configured to store the standard user folders (Documents, Pictures, Music, Videos, and the Desktop) inside the folder synced by the Google Drive desktop sync application. This ensured all user files were automatically backed up to cloud storage and helped adoption of Google Docs by presenting Docs files alongside traditional document types in the Windows user file space.
Keeping an automatic backup of user folders (e.g. the standard ‘My Documents’ folder) has always been highly desirable on Windows networks to ensure user data cannot be lost through failure of the user’s workstation. On domain computers this has traditionally been achieved by using Group Policy Folder Redirection to move user folders onto a shared drive on a file server, and backing up the file server. With the increasing prevalence of 1:1 device provision, high bandwidth Internet connections, and the availability of almost unlimited cloud storage in Google Apps for Education, it became clear that using Google Cloud to backup user files might deliver advantages over the standard on-premises file server model.
While users already had access to both a mapped network share and Google Drive, few users had taken the initiative to store any large proportion of their files either on the network, or in their synced Drive folder (if they had set up sync at all). Neither roaming profiles nor folder redirection were in use, so most users simply saved files to the default Documents folder, stored only on the internal hard disk of their laptop or desktop. In the meantime, the size of hard disks on individually assigned devices was such that total user data size had grown substantially over the years, and setting an automatic redirection to a network share would have outstripped available file server space several times over.
Numerous difficulties had arisen over the years with this approach, as files would sometimes be lost when hard disks failed. IT staff would also spend large amounts of time transferring files when users had to have their workstation replaced. As such, a backup solution was required that would require the user to change their behavior as little as possible while ensuring that the entirety of their locally-stored data was backed up and could be easily restored to an alternative workstation.
The natural solution was to use the standard Group Policy Folder Redirection feature to automatically move user folders into the C:\Users\username\Google Drive location, instead of using it to move the folders to a network share. However, this had two major problems:
Since its initial launch, the Google Drive sync client required the local Google Drive folder to be completely empty when sync was first set up. This meant that pre-populating the Google Drive folder with user files before the user had a chance to sign in to Google Drive would prevent sync from working. However, updates to the Google Drive sync application in late 2014 allowed it to sync a folder with existing files, correctly reconciling the changes with Google Drive storage.
Limitations in the user interface of Group Policy Folder Redirection meant that attempts to use it to redirect any folders to the Google Drive subfolder within the user profile location resulted in the folders being placed at the top level of the user profile – i.e., in C:\Users\username – exactly where they were by default. Any attempt to use the Google Drive subfolder would cause Folder Redirection to automatically switch to the built-in Redirect to the local user profile location option.
The latter limitation was overcome by setting a new environment variable (%GOOGLEDRIVE%) pointing to the Google Drive folder for each user via Group Policy Preferences, and then instructing Folder Redirection to reference the environment variable (e.g. %GOOGLEDRIVE%\Documents), essentially hiding the local location from the Folder Redirection UI.
Once this was done, the following user folders automatically became subfolders of the default Google Drive folder at login:
The Google Drive sync application was then deployed to user’s computers via SCCM, leaving only one step manually performed by the user: logging in to the sync application using their school Google Apps account.
In the first 2-week period of introducing the change, over 1TB of user data was backed up from user workstations to Google Drive cloud storage – data that previously had no backup. As of August 2015, Charles E. Smith Jewish Day School stores over 2TB of data on Google Drive.
Lastly, training was provided to employees on the use of 2-factor authentication for their Google Apps accounts, to ensure that Drive data remains secure.
Update: March 2016
8 months on, this solution has proven extremely effective with very few problems encountered during implementation or over the long term. However, there are some minor issues we encountered that should be considered:
When implementing Folder Redirection, the files & folders being redirected are moved synchronously during user logon. This will cause a one-time logon delay the next time the user logs on after the Group Policy settings are applied to the user’s account. The delay will be proportional to the size of the user’s data, and will be slower if their computer has a traditional hard disk instead of an SSD. Most of our users had SSDs and experienced a delay of less than 5 minutes. Those without SSDs typically experienced a delay of less than 10 minutes, though these users had less data on average than those with SSDs. Your user experience will probably vary, so you should test with some typical pilot users and prepare the remaining users for the delay when you implement the Group Policy changes.
We encountered Folder Redirection failures with a very small number of users (<1%). Ideally you should have a system that monitors the Application event logs of your workstations, and you should check for errors from the Microsoft-Windows-Folder Redirection source. There were two causes of errors that we observed during implementation:
Folder Redirection does not strictly move the folders it redirects; it makes a copy, then deletes the original. This means that if any 1 of the redirected folders has a total size exceeding the free space on the disk, the redirection for that folder will fail as Windows will not be able to create the initial copy.
If the user has files or folders that have very long names, or are in a deeply nested folder structure, their full pathnames may be close to the 260 character limit defined by the Windows API. If this is the case, the addition of 13 characters to add “Google Drive\” into the name may put the files over the 260 character limit, and those files will not be redirected to the new location. On Windows 8.1, exceeding the character limit will be clearly identified in the event log. On Windows 7, only the somewhat cryptic message of “The semaphore timeout period has expired” is logged.
When users update their passwords, the Google Drive sync client needs to have the new password entered to continue syncing. Users frequently do not notice the prompts from the sync application, so we now have a script running every 10 minutes as a scheduled task that looks for password changes in AD (which are synchronized to Google apps in our environment using Google Apps Password Sync) and emails users an instruction sheet.
Every few months or so a user decides to ‘tidy’ their Google Drive and moves one or more of the redirected folders to a subfolder, resulting in all their files disappearing from their Desktop and other folders. When this happens, we move them back and remind them to leave those folders at the root of their Google Drive.