Re: [ADSM-L] Backing up desktops/workstations
2012-12-10 11:38:23
A separate server seems reasonable if you have thousands of nodes, even
if there's only a few files per node. I'd be a bit nervous about
excluding media files, since there can be legitimate uses for them
depending on the user. Maybe you could have an opt-in for backing those
up, with a signed form on file stating that the user will store non-work
media files in a non-backed up location?
We've side-stepped this issue by generally not backing up desktops[1].
If a user wants files backed up, the policy is that they should end up
on a file server we do back up.
[1] Our desktop support team does offer limited backups of desktops and
laptops via Iron Mountain's Autonomy service. I would have preferred
TSM, but I can't complain since I'm not involved with it at all. It
seems to work adequately, although it's somewhat expensive and very slow
on the restore side.
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine
On 12/10/12 07:42 AM, Zoltan Forray wrote:
I am looking for war-stories, experiences, suggestions, ideas from you
folks that have implemented backing up desktop machines, which could expand
into thousands of additional TSM nodes.
I have been tasked with looking into doing this. The current guidelines is
to "only backup 'documents and settings/users' folder, excluding all music
files (mp3/wmv/wav/flac/ogg)".
My first thought is to stand-up a new server (or two). Create a default
policy-domain with short retention (30-days or less) with few copies (2)
and a cloptset with an exclude everything and include doc & settings/users
plus exclude or the music files.
--
*Zoltan Forray*
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html
|
|
|