Editing InDesign Files Directly off a Server: Crazy?
C.P. wrote:
Can you give me any information about suggested minimum or optimal server space needed when using CS5? We noticed an increase in “crashes” last week when our server space dropped to 7 GB. Our IT department said to let them know when it dropped to 1 GB of usable space.
Okay, it’s time to bring this fistfight/argument/debate/discussion out into the open:
David: I don’t believe in servers. Well, okay I believe in them, but having grown up in the 20th century, and being superstitious about technology (I still have scars from dealing with SCSI termination voodoo), I have a strong preference for the copy-file-to-local-machine-edit-save-then-put-back-on-server workflow. I know it’s painful and inefficient, I know it’s old-fashioned, but running all those bits and bytes along network wires, subject to the slightest hiccup or network drop just freaks me out. InDesign files are a database of information, and there are no tools for salvaging your database if it gets corrupted.
Anne-Marie: David, oy. :D I wonder if you’ve left your computer cave since 1992 and seen how companies are set up these days? Networks are quite a bit faster and more stable than they used to be. Yes, digital retouchers may be working on their 500MB images locally or off of an attached scratch disk, but when a company has a server and an IT department, it’s quite common for all the other users to work directly off the server. I mean, I personally know of hundreds of of my own training clients whose networks use InCopy/InDesign CS-whatever on a shared network server. That is, after all, how Adobe’s documentation requires it to be set up. I keep up with my ID/IC clients and other than the occasional glitch (server or otherwise) have not heard anyone say that IT decided they can’t run off the server. And of course there are tens of thousands of more users who work off the server routinely, it’s the standard operating procedure for most company networks for the past 5 to 10 years.
That said… seriously, only 7GB free on the server’s hard drive? Out of what, like a 500 GB hard drive? That sounds like a bad idea to me. I’m pretty sure most hard drive manufacturers recommend you keep 10% of a hard drive’s capacity free (whether you’re talking local computer or server).
David: Okay,that’s a good point about the free hard drive space. Computers do need a lot of scratch space to function sometimes. But Anne-Marie, you’re working on an InDesign file that’s sitting on a server and after a while the network jams up or goes down for 30 seconds. It happens to be right when you’re saving the document. Hosed file?
Anne-Marie: I would imagine that if the network jams up or goes down for 30 seconds, it’d be the same as if your own computer went down or froze. Not good! :D Your temp file and your cache are still on your local computer, as far as I know. So, save early and save often. More important, if you have a flaky network, then the responsibility is on the IT department to make sure it’s not flaky.
I hear what you’re saying, though, David. Working off a server adds more variables to what could go wrong. Not just a problem with your own computer, but also with the server, and with the connection to the server. That’s all true. What I’m saying is that in my experience, many (most?) companies with enough computers to warrant a server have users opening and saving files to it all the time, because in balance, there are fewer problems with that workflow that with users constantly copying files across the network so they can work locally. I know for a fact that part of Adobe’s own internal testing involves working with InDesign files over a server, too, because they know that’s how a lot of their customers will be using InDesign.
A Server Expert Weighs in
We turned to Ben Greiner, owner of Chicago’s Forget Computers for his advice. Anne-Marie has known Ben for years. He and his company specialize in supporting Mac and mixed-platform networks (using Mac or Windows servers) for design firms, ad agencies, and publishers. He knows his way around the Adobe Creative Suite – by osmosis at least – and supports a number of clients who are using a server-based InCopy workflow.
Ben: David’s fears are valid, although I agree most with Anne-Marie. Yes, you can work directly off the server. Although it is not uncommon for a wireless network to have sporadic issues and temporary outages, wired Ethernet networks should not have these problems unless there is a failing piece of hardware or an electrical problem (in either case IT needs address the issue). Regardless of the network, I do believe InDesign will cache a copy locally and in most cases recover from a server/network disruption. (Although, yes it will fail to recover when you *really* need it, so backups are important. :-)
We have many clients working directly off the server with InDesign, yet we receive very few (if any recent) calls involving “hosed” InDesign files.
That said, I’ve seen clients try some things that have failed. Opening a 100+ page InDesign file from the server and saving as a press-ready PDF might fail. Opening and editing nearly 100GBs of Photoshop files directly from the server might fail.
Unfortunately, many IT departments try and “shoehorn” creative professionals into a technology infrastructure that was built for Microsoft Word and Excel. In this particular situation AM is correct when she questions usable disk space. Unless all the data will fit comfortably on a floppy disk, more than 1GB must be available on the server! At least 10% free is a common rule.
The server, storage destination, and network (Gigabit Ethernet is a must) all play a part. Any IT department worth its salt (or Sodium Chloride as the geeks call it) can build an infrastructure that will support a server-based InDesign/InCopy workflow.
_______________________
There you have it-and thank you, Ben! We’re still recovering from the “worth its Sodium Chloride” remark :-D but other than that, your information was much appreciated.
We put it to InDesignSecrets.com fans: What do you think? Are you editing InDesign (or other kinds of files) directly off a server? Please share in a comment below!
 |
When I’m forced to work off a server, the failure rate is much less than I expect, having grown up in that same 20th century that David mentions. And the local InDesign cache is an excellent point: No matter where the failure occurs, the backup is on your hard drive.
To me, though, the most amusing thing in this post is the reference to a 100+ page InDesign file as though that’s large.
“Are you editing InDesign (or other kinds of files) directly off a server?”
YES. Mixed environs: Linux server, OS X and Windows machines. Nightly backups made automatically to a remote location. Editing huge files, no problem at all — virtually never.
CS5.5 (trial) crashing *numerous* times, but that all had to do with some flaky Word files where ID happily ignored the junk that came with it but the ePub export couldn’t mentally deal with.
And I agree with Keith above. 100 pages? Pfff. I do that before lunch. Largest file I edited so far was a whopping 750 pages.
(Then again, some time afterwards I decided to split it up in 35 separate files, ’cause the lag was pwning me.)
We are using InDesign/InCopy workflow (all files stored on local server) for years and so far so good. Obviously there are workflows which benefit little or not at all from such a setup but in environments like these (f.e. ID/IC + photo editor) there is simply no other choice.
Like David, I remember a time where we feared our syquest cartridges wouldn’t survive the delivery via bike messenger. And I have many clients who work directly off the server and experience no (or very few) issues. This is strictly the case with InDesign files though. I never recommend that clients work directly off the server when dealing with Illustrator or Photoshop files. Those applications don’t create temp files like InDesign does. Nor do those apps know how to write “diff” saves — meaning only save the data of a doc that was changed since the last save. The chances of an AI or a PS file getting corrupt are far greater than the possibility of losing data with an InDesign file. Hopefully this gets better in the future, but that’s the reality now.
On a related issue, with so many of my clients, I see similar issues where IT departments don’t fully understand the requirements of graphics departments. If a design department is working on large files off the server, then they should NOT be sharing a server with the rest of the company, and they should optimally be on their own subnet so that the overall company network traffic doesn’t interfere with them (and likewise, the design department’s strains on the network don’t affect the rest of the company).
Oh, and besides lots of free space on the server, it might also help to load those design machines up with gobs and bogs of RAM :)
Of course Anne-Marie’s expert agrees with Anne-Marie! But I agree with him too, except for:
OK, so I haven’textensively tested it (famous last words), but I did not think it worked that way. As I understand it, the InDesign Recovery and InDesign Saved Data mechanisms save a copy of the database transactions that would be written to the InDesign Database (INDD) file, if you were to hit Save.
So, if InDesign crashes and restarts, the original file is re-opened and the same sequence of operations that you did before is re-applied.
If the original file changes out from under you because of a Network Act of God, this mechanism is of no help to you. It does not preserve your original file in any way, only the changes to it that you made in the active session.
On another note, we had a discussion about this on the Adobe InDesign General forum last month: Network Timeout freezes InDesign.
I said a lot there that I won’t repeat here, but basically: networks are complicated and they can bring out corner cases you otherwise would not see. Most problems where InDesign misbehaves on a network are either problems with the network, or subtle InDesign bugs that need to be fixed. In order for that to happen, the bugs have to be reproduced and documented and reported. And it’s really important that that happen because everybody uses networks.
On the gripping hand, for our production work, we use Woodwing SmartConnection Enterprise which is primarily about InCopy integration, but has the side effect of making a local copy of InDesign layouts for InDesign to operate on. So, indeed, in my environment, most of the time, InDesign is not used with a network file server in the normal sense of the word.
Great article! I work with files off the server and it’s slower, and sometimes I have to wait for about 30 seconds while “something” is going on…I don’t know what, but there are hiccups occasionally. The problem is not just with InDesign or Photoshop. My Finder window sometimes freezes because it’s trying to access the directory on the server. Other programs, such as Microsoft Word or Excel, may behave the same way.
When files are on my local drive, everything runs so much smoother. However, it’s the office’s policy to save all files on the server, because the server gets backed up every night.
I can understand the fear, but I’ve been working off a server and it’s been great. Since designers at my work share projects, you never worry if you’re working on the latest file. If someone is working on it, it won’t open.
I’d be afraid of forgetting to copy the latest version and then have two different files with different edits if we copied from the server and re-uploaded.
Mordy, I’ve noticed that working with large layered psd and ai files can take a bit to open and save, but we’ve been lucky with not having any issues. (knock on wood). But I agree that if you had a massive file, it would benefit working on it locally, if not just to save the time spent saving it.
Great piece! I hope to see more “He-Said/She-Said” articles!
In my experience, working from local files encourages bad habits, like linking to artwork on a user’s desktop without making sure that art is on the server. I’ve occasionally had problems with server hiccups (thank heavens that InDesign has a good recovery feature!), but I’ve had a lot more frustration from dealing with duplicate files or from trying to track down local files from designers.
Longtime ago, I used to freelance doing production at bigshot ad agencies in NYC.
The server versus local was an even more serious issue back then (not to mention the SyQuest vs. Bernoulli knucklefests, but that?s another bag o? bits).
As a practical matter, networks were slow and jigged up for relatively small files. Art departments had to hew to a local machine policy. You got the job folder form the server, worked locally and reuploaded when done.
At a certain agency that shall remain nameless, most people would just delete the local file right after the reupload and that was that.
I never met a machine I could trust. I had the habit?when I was done reuploading?of moving the job folder in question to a temporary desktop folder and kept it there until the following week. On Monday, I would empty that folder and start over.
One Friday morning I came to the studio to see a situation of absolute panic and terror.
Overnight, the servers crapped out. Massive failure.
Deadlines loomed, major releases due at newspapers, magazines, you name it. Because product launches wait for no one.
The tape backups were incomplete (anyone who’s waited for a restore from tape knows that’s a quick way to sainthood, patience being a virtue and all that) and practically useless.
I had plenty of usable files in my local desktop, but I did make a lot of overtime $$$ helping get other jobs out. Keeping job files locally for a few days became studio policy.
And the studio got its own server, something the studio manager had been lobbying for fruitlessly for a long time.
I’m glad to hear servers are more dependable now (even my own). But the only certainty in life, other than death and taxes, is Murphy’s law.
Me, I’m still hedging my bets and work locally. And backups, many backups in different places. There are two kinds of hard drives: those that have failed and those that haven’t, yet.
Yep, big believer in backups here, too! In addition to Tiime Machine and SuperDuper, thank heavens for Crashplan and Dropbox. Each one of these has saved my bacon in the past few months.
Many of the clients I work with who are required to work off the server do so because IT only backs up the server. Users are warned that anything they keep on their local hard drives is there at their own peril.
Though I worked with a client last week who just set up a new local server network for ID/IC and their IT guy told me their backup system backed up both the servers and the local machines. Which I thought was pretty cool.
We have huge amounts of files on what amounts to a home network, absolutely no problem…
I find the funniest thing in this post the reference to a floppy, what the heck is that?!!!
I do all my editing on files stored on a server. My only mistake is accidentally deleting one and then realizing it didn’t go to the recycle bin. But since we have overnight backups I’ve never lost a document in over three years! If InDesign crashes or the network goes down the backup is usually saved right at the point the crash happened. This is technical literature for a major US manufacturer.
Now when we were working on Quicksilver (Interleaf) . . . well, that’s another story!
We have a NAS as our “server” and use Chronosync to pull down files, work on them locally, then Chronosync again to push changes back to the NAS. No issues and it keeps versions of every file automatically.
I’ve worked off a server from CS-CS5 and have not had any major issues. Some of the networks i’ve worked on have been fairly “home made” without proper IT personal, and i’ve never had any major issues. When I switched companies, they couldn’t believe that I would “risk” working off the server, but it has always made everything a little bit simpler and more streamlined. I hate having to jump from computer to computer to locate a file that someone else has worked on.
That said, if i’m working on a large file ~75mb or more, I copy it to my desktop and work from their, just because I seem to have less issues with big files if they are on my desktop.
I work off of a server all the time … it’s in my basement with tons of storage so I can be in the living room with my MacBook Pro :) … I work with everything from movie files to mp3s to the Adobe Creative Suite and only rarely have issues (and those only involve movie files that are well over 4GB a piece) … unless you’re working with really large files, it should be fine. Especially if you’re on Wireless-N and gigabit (though 100Mb/s works just fine). If your network isn’t fast enough to do this, then you probably have an issue with your network. Might want to do some troubleshooting, tweak your TCP/IP stack (esp if you’re on Windows), and double-check your wiring :) … and this is just at home … at work (small college), everything’s hosted on a centralized NAS … files on local hard drives aren’t backed up, but the NAS is, so everyone works directly from the server without issue :) (including many students)
InDesign doesn’t cache a copy locally
OK, I believe I was correct to be skeptical about Ben’s claim about local caching. I went and experimented. At first I thought I was wrong — when you open a document, InDesign does create a fairly large DBTmpnnnn file in the InDesign Recovery directory. But it’s only about half the size of the original INDD file and it does not appear to be useful in recovering the original INDD file in its absence.
I tested two common network file failures.
First, I opened an INDD file, made a small change, erified the InDesign Recovery files were present. Then I deleted the file and Force Quit InDesign. Restarting InDesign, it complained about the absence of the original file and offered to let me postpone recovery, but could not recover without it.
Next, I repeated the experiment but instead of deleting the file I overwrote it with all zeros. (It really sucks when networks break files this way, but it has been known to happen.) Upon restarting, InDesign tried to recover but complained the original file was corrupt and did not succeed.
My conclusion: Recovery is only useful for recovering from InDesign (or machine!) crashes, not from external events that damage the original file.
Some replies to other comments:
InDesign vs. Illustrator and Photoshop
Mordy Golding suggested that because InDesign saves differences incrementally, its use of the network is safer than Illustrator and Photoshop’s, because those apps rewrite the entire file. (I’m assuming they really do rewrite the file. I haven’t dug under the hood and tested/probed/benchmarked them.)
Unfortunately, I do not believe this is a valid conclusion. InDesign’s behavior is certainly faster. But that does not make it more reliable. Generally speaking, a network filesystem is more likely to fail changing an existing file than it is writing a new file. And removing an existing file and writing it anew is really akin to writing a new file.
[ Also, in a perfect world, apps that rewrite the whole file would write the new file before removing the old file. So that, if the client machine crashed in the middle of the save operation, at least you would have the older file. I’m not sure if that’s how PS and Illustrator work though. The one downside is that you need enough extra disk space for 2 copies of the file. But nobody should be redlining their system that far anyhow. ]
(On the other hand, the fewer writes to the server, the less opportunity for something to go wrong. But I still think you’re a lot more likely to encounter a failure from a short append operation than you are from a wholesale write-of-file operation. But there is a counterargument for sure!)
On their own subnet
It’s dangerous to dictate network architecture from afar. Assuming we’re in the same campus, rather than dealing with a wide area network, LANs, switches, and routers have all gotten fast enough that there’s no need for servers to be on the same subnetwork as clients. They need high-speed low-latency connections to clients, but that doesn’t have to mean the same subnet. It’s really about how the IT folks care to engineer their network, and it should not affect reliability.
(That said, it’s probably true that more there are more unreliable networks with servers far from clients than there are reliable ones that way. But the world is changing and it need not be so.)
Good to know, John, and thanks for that detailed and thoughtful post.
I still say that the proof is in the pudding … or the pudding is proven when the poof is puddling … something like that.
The fact is that a sizable proportion of InDesign users who work in places that use a file server are working directly off the server (as the commenters above can attest). The advantages of that way of working are simply too great in comparison to the relatively rare risk of file damage (which is usually recoverable, or via an automated backup as a last resort).
I can see why creatives would prefer working off the server. It’s fast, it’s convenient, etc. but it really depends on your network switches, bandwidth, computer processor, how much traffic is on that subnet and essentially what Adobe recommends. Adobe doesn’t recommend it. With sensitive updates to Adobe’s creative suite, updates to Apple’s OS, the possibility of file permission levels changing, along with various network activity…such as backups, virus updates and the latest sports match that everyone has to watch. All these things interfere with network activity… I think when you have all those variables, I would highly recommend working locally.
Working on a server, I used to do that, but not anymore!
On a small network (4 workstations of witch one is the server), a few times a week the server was down, looking the other way, lost it’s connection, or what ever. Indesign commits suicide when it could not save the file.
The time taken to copy the file to a local workstation, work on it and copy is back is a lot less than waiting for Indesign to fire up again.
Would be nice if indesign up on realising the network was off, not died, but gave the opportunity to try a save again or save local.
And no, We do not have an IT department
We work off our OSX Server with no problems at all. Its a small 15 machine set up.
No speed lag, it just works.
I agree with Anne-Marie about saving early and often, I know it seems like an obvious thing to say but I have seen so many cases where this mantra is ignored.
Plus I am very nervous of a workflow that has multiple versions of files copied backwards and forwards by human hand.
Interesting posts here, some great info.
One caveat is when you are remote from the server and you delete a file, that means delete, no move to trash, no undo.
We have been working from server based files for about 20 years here, always Windows servers, RAID and currently using Extremez-IP running on Windows 2003 servers, with about 9 TB space. No problems whatsoever using all Adobe programs. Also our Windows based clients, using financial and administration software are on the same network. I am also the system-administrator, and we have about 98.000 files on the disks.
Now and again we do have a power failure (very rare in the Netherlands) but the UPS picks it up, and Indesign’s recovery works very well. I never thought people would hesitate to work from servers, is this something that used to be advised? Anyway, our experience is pretty solid. The server-disks can easily be upgraded and space is never an issue.
For even the smallest workgroup, I would recommend some kind of version control. Too much room for error without version tracking and check in/check out. Bigger workgroups will find it productive to use DAMs and CMSs, but if you are small something like the old version cue might be in order. There are challenges with all these approaches beyond cost but if you want to monetize and reuse your content, you are leaving money on the table with an unsystematized workflow. As far as the physical layer goes, there are good networks and storage systems and there are bad ones. Folks who prefer to work locally are usually doing so in reaction to a bad network experience and I don’t really blame them. It just makes collaboration and reuse that much harder to retrofit when the time comes.
I work off a server 100% of the time. I have virtually no problems with it. I don’t want to store any work locally because the servers get backed up every night. I don’t experience any noticeable drag time, though several years back I did (so worked locally back then — that was at least 5 years ago, maybe longer).
Thanks, Phyllis
I can’t even believe this is a debate. Work off the server! Our servers are backed up, our desktops are not.
Work off the server and buy some more hard drives! They are cheap! I realize good backup options are tough in small environments but your data is your livelihood and it should be protected.
InDesign will die if it looses a connection but for the life of me I can’t recall ever losing a document. Ever.
We also have gigabit Ethernet, so things move around pretty quickly here.
@Bob H: Glad that works so well for you, but why on earth would you not have your desktops backed up? Get crashplan or something!
Most all companies I’ve worked at since 1994 have worked off the server. The difference is that in the earlier days when networks were slow, only small .fpo images were used in layout programs (Quark at that time). Now, hi-res images are used, but the files are broken up into manageable pages.
I had thought that at sometime in the past (maybe InDesign CS2?), working off of a server was NOT recommended. I may be wrong.
However, I don’t think I would trust opening/saving large file off of a wireless network.
InDesign’s recovery file, whether working from a server or locally, requires the original file in addition to the recovery file to restore after a crash. The recovery data is not a changing copy of the original; it acts more like a patch file.
So John’s observations about network behavior apply equally to local files. The recovery files ID created for a 28MB document totaled about 6MB after a couple of minor changes, and didn’t change size through a number of additional ones.
ID can’t recover from a simulated crash (killed process, in this case) without the original file being present and not corrupted.
I’ve worked with ID across networks and locally, and in my experience reliability issues are neither greater nor less either way given a good network infrastructure.
David’s method of copying a file locally and then copying back to the server when finished is fine if only one person is, or will be, working on a file. However, where I work we often have multiple designers taking turns at working collaboratively on files saved on the server; this is where InDesign’s file locking is useful. It throws up a red flag that someone already has the file open and that it’s currently unavailable. Imagine the chaos if we had people copying the file to their local drive and then copying it back to the server; the potential for overwriting someone else’s work is huge. Ouch!
Make IDML the default format, make it load/save faster and I move my files to server.
Then again the idea that anyone can create native Indesign files without buying the program would probably scare Adobe very much.
@Marcel: IDML is Adobe’s recommended format to create files outside of InDesign. They provide ample documentation, utilities, and samples for that.
I’d hardly call that “scared”.
(Those devious no-gooders still maintain you need InDesign to actually do something with the IDML. One of these days we’ll get’em for that!)
A cautionary tale.
I work in a government department and our practice is to work directly off the server. We had an interesting snafu a couple of years ago that still affects us from time to time.
It’s a Windows based environment that we work in, and our main production server is the “R-Drive”. A couple of years ago IT put in a new server to replace the old R-Drive and remapped our computers to this new server. So on the surface the path to our files has remained the same. But because the new server is physically in a different location, the actual path to the correct IP address is actually different. Because of this, when we try to open any files that were on the server prior to the switch (which at the beginning was all of our files), it can take anywhere from 10 to 30 minutes for the file to open. My guess is that in the background ID is trying to resolve the paths to the various linked files. We’ve tried to work with IT to have this resolved, but no solution was ever found.
As we worked on more and more files it became less of an issue as the paths would be updated anytime we opened and saved a file. Although it is still a lingering issue, when we periodically open an old file that has not been accessed since the switchover.
If your IT department is ever talking about updating your server, please keep this in mind. If there is any way to have the new server installed under the old IP address, it could save you an awful lot of thumb twiddling time!
For the record when this would happen, ID would actually appear to be dead. It would actually show as “Not Responding” in the Task List and nothing else on the computer would respond either. We would have to simply let it sit there chugging away, and the file would eventually open.
We almost always work off the server. When we will be traveling or working offline, we use MS SyncToy to pull down a copy of the project folder.
If you do copy files to your desktop and use books, be careful. Remember that the book links to specific file locations. For example, if the book links to the documents on the server, the book on your desktop will still point to the server. You will not see edits made in your local documents until you copy them back to the server. Even experienced InDesign users get confused and waste a lot of time trying to figure out where their edits went.
My suggestion is to either only work on the documents when offline OR use two book files: one pointing to the server and one pointing to the desktop.
Finally, in our Windows environment, we do experience frequent InDesign crashes. The documents are usually recoverable, but occasionally get corrupted. No other applications seem to be affected, so it is extremely difficult to identify the cause.
The ProtectiveShutdownLog entry looks like this:
Adobe InDesign Protective Shutdown Log
07/21/11 16:32:41
Lost network connection of open database
Session started up at 10:35 AM on Thursday, July 21, 2011
Version: 7.0.4 - Build: 553
No Error Info
I’ve freelanced at more than 40 companies over 20+ years, and almost everyone’s worked off the server or some kind of central and/or studio storage. I recently worked in a one-person production studio of a large ad agency (sadly, the number of production studios doing solely print design & production are dwindling, fast), and they had a ton of rules: don’t work off the server, keep your filenames to 26 characters, use underscores for spaces, collect ALL linked art and fonts into the job folder of anything you work on.
I felt like I was back at Arthur Andersen, circa 1994, when I was one of two designers on Macs in a company of 1500 PCs running Windows 3.1.
all server, all the time. been doing that with indesign since i started in CS1. can’t imagine doing it any other way (unless maybe i was working in a one-man shop).
In our office, local InDesign work files are stored on a networked file server with mirrored drives. Every three hours the server is backed up to an identical mirrored file server. A backup job runs nightly to move files from the second server out to a remote backup site.
We use a lot of freelance editors, and all of -those- book files are kept in Dropbox folders, so they are stored and managed on the Dopbox servers (even though Dropbox maintains local synced copies).
Networks are so fast these days that there’s practically no delay opening even a large book file, and I love the flexibility, availablility , and reliability that networked servers offer.
Great article. Loved the Syquest reference, made me chuckle.
As a studio guy nothing strikes fear into me deeper than the thought of a room full of art directors all working from desktops. Have you seen some AD’s desktops? they’re a sea of google grabs, CS files, copy docs and web links (shudder). I’ve had that sheepish AD shuffle up and confess to having accidently deleted a file they’ve been working on all week. Server all the way! Take a copy home to work on (if no remote working is available) but don’t keep it there.
That said, they’re just as capable of making another version of a file and saving it over the original on the server oops.
With 1Tb drives costing $60 these days, small to medium studios can afford to have time machine hourly backups available of everything while more enterprise level systems can take care of the nightly archiving. You could have time machine backups of every mac on the network but that might encourage them (wink).
Here’s another little tip that just popped up on this subject, from Macworld Australia: https://www.macworld.com.au/help/reader-tip-working-with-files-on-a-server-36258/
My op: using the server to edit is not a good idea for remote users. If you are accessing on local- then the problems may be minimal. But using the server to edit files remotely is just asking for trouble.
The standard workflow for video professionals is GigE for non-HD and now 10GigE for HD (because it’s cheaper than fibre channel). So yes you can build a wired network that is extremely reliable. Video people push/pull way more data than InDesign or Photoshop are. However, because of this, any network problem will immediately cause major problems, therefore video networks are rigorously configured and tested; perhaps unlike, as Ben points out, the typical Word and Excel demanding network.
So absolutely it’s possible, and due to the greater workflow efficiency it offers, should expect to be fixed or redesigned if it isn’t working.
I would like some feedback on this if possible:
I currently have around 50 Macs (designers) and 40 PC (administrative) users all 1GB to the switch then switch to my main core switch via 10GB fiber This switch is connected via Link Aggregation to my File Server for 2GB throughput.
File server (Windows 2008R2- 32GBRam) connects to a NETGEAR READYDATA 24TB Raid 5 via 2 ISCI. One is for The administrative Volume and the 2nd for the Creative Volume.
Based on all the concurrent users hitting the server. Would it be possible for the Designers work of the Server with 500MB Average file sizes for Indesign and Photoshop?
Thank you for your thoughts and input.
Jason
I’ve only been in the industry professionally for about two years, but working off the server is the only way I’ve worked at two different companies. The only problems I ever had are because of shotty server equipment at my current employer, but the time I lose because of system failures is minimal when compared to how much faster my iMac is than my bosses (same age and specs) i5—1TB storage, 10% full—16GB memory. My boss has only about 10% of his space left, and works off of his computer. He is constantly complaining.
We’re running InDesign CS6 from Mac’s off of Windows network/servers, and we have all sorts of problems writing back to the server. It was suggested that we get a designated Mac server, but our IT dept. wants none of this. Our workaround is to write/save locally.
Having dealt with a number of clients over the years I’ve had few problems with working directly from a server, but at one point and this might have been the CS3 days (possibly still is) adobe did not support working over a network (we always pushed forward with it though).
Think the problem with a lot of IT departments is when the design teams start to request new servers or more storage the IT department will either have no budget and have to request on an as by as basis for new hardware or their budget just won’t stretch that far.
My experience of design firms is they will happily by new workstations for users as they get jobs and have to employ people to complete the work, but put a request in for some extra storage which could cost anything from £2k up the finance departments don’t understand what the money is for and don’t want to understand why they need to spend another chunk of money on more kit.
First, when free server space drops below 10%, you are looking for problems, Microsoft apps or Adobe apps.
Second, a chart describing InDesign cache files is here: https://helpx.adobe.com/indesign/kb/indesign-preferences-support-file-locations.html. In addition, it appears InDesign creates a temp file (a lock file) that is stored in the directory where your file is. So if the file is on a server, the temp file is on the server. It is the temp file that puts a lock on the file. What I’ve seen is that this temp file doesn’t get deleted when the InDesign file is on a server, keeping the original InDesign file locked. I’ve also seen where the temp file has different permissions than the original InDesign file, in essence locking the file.
Third, an InCopy/InDesign server-based workflow is a bit different than simply working directly off a file. The InCopy/InDesign interaction has intermediate files involved, much like a relational database. You are editing linked frames that have been published and are being managed, minimally, so that only one editor is in each frame. I know it is heresy to mention it here, but the Quark Publishing System is based on a true relational database, further isolating it from individual document hiccups. That said, individual InDesign and XPress documents opened directly from a server are susceptible to network, server and operating system hiccups, causing file corruption.
Fourth, if InDesign users are having frequent crashes, locked files or corrupted files while working on the files from a server, I would disable background preflighting. Whether you are working on a local or remote computer, background preflighting can slow you down a bit.
Last, at the time this article was originally written, and through CS6, Adobe didn’t/doesn’t support working on Photoshop and Illustrator files from a server, unless integrated with Adobe Drive (which is a database system). https://helpx.adobe.com/photoshop/kb/networks-removable-media-photoshop-cs5.html
To reduce spam, comments are closed on this post.