Deleting the _backup folder or .RWS files

[Rustle]

We are trying to keep our network disk space under control and we are wondering if we can delete the _backup folder or .RWS file in that folder. Revit seems to recreate them every time you save to central and not complain if they are not there. We are looking at running a script that deletes them if they are more than 15 days old. It is only about 50GB but it all adds up. We tell people to audit and recreate the central every week so this should not be a problem right?

[twiceroadsfool]

That backup file lets you roll back the central file in the event that something bad happens, or someone makes a major error that doesnt get caught for a little while...

Storage space is cheap, buy more... Save the backups.

[ron.sanpedro]

That backup file lets you roll back the central file in the event that something bad happens, or someone makes a major error that doesnt get caught for a little while...

Storage space is cheap, buy more... Save the backups.

Good argument for robust (and large) Shadow Copy implementation.
The RWS file never goes to tape, and leaves the primary server disk weekly, but the whole folder is available via Previous Version as needed, perhaps going back a month or two. Given that Shadow Copy is a bit by bit differential, file size for the Shadow Copy stays small, and there is fallback for 'oh $#!%' moments. All hail the really big Firewire/eSata drive.

Gordon

[Rick Houle]

I only recommend keeping the backup folder for the most recent Central archive.
The way i see it, and we also "SaveAs" our Central files regularly, is that the backup folder is a CYA (cover your a**) feature that only serves a purpose for a limited number of days/weeks... The data times out as work in the new central continues.
ON one occassion I have had to revert to an "archived" central AND it's accompanying backup folder... and the only reason it served a purpose was because it was only two days old. Anything older than a week or so, let's be real, i'm going to restore my work from tape backup before I lose that much ground...

oh yeah, we backup our server differentials every evening... So, I always have a tape backup of yesterday's effort... heck of a safety net.
I guess that kind of nullifies my opinion here...

[Rustle]

Thanks Gordon I forgot to mention we have copies of all our files from noon and midnight each day as well as tape backups if we need to go back more than a week. That actually the point of all this. We are an 80 person all Revit firm and our tape backup time/capasity is getting too big for our current technology. I usually just create a new central from a working local if I can.

[chodosh]

On one occassion I have had to revert to an "archived" central AND it's accompanying backup folder...

Well, well, sparky, aren't you a lucky chap?

I really hate to sound snarky. However, in my experience (which I will readily has been perhaps unique) you can *never* delete the backup folders without seeing some complications. And, I have been able to successfully restore several files from the backup when all copies on the tape drives and other backup systems of the actual *.rvt's could not even be accessed. Let me qualify that specifically, I have found that you should *never* remove any backup folder or Revit_temp folders for any file that is *actively* related to a project involved in worksharing.

The backup folder and the Revit_temp folders it would appear cannot be treated as static backups, ***especially if you have more than one file linked together***.

I would strongly suggest removing them only after time has elapsed or they are irrelevant to a new file. As Rick says, keeping the backup folder for the active Central file is a good practice, but I would also keep the backup folder for the locals, too. Especially if you do not create local files every day. Acknowledging that there are divided camps on both sides of the local file creation debate, if you do create new locals, you can remove the backup folders from the previous local file without complication.

I forgot to mention we have copies of all our files from noon and midnight each day as well as tape backups if we need to go back more than a week.

Having the files at mid-day I imagine has saved you time and again. However, with Revit in a worksharing environment you may be able to rely instead on a mid-day restore from a local file and therefore may not need to backup your *.rvt's as frequently in order to shave down on the storage load from your Revit projects.

Just my $.02.

Nice point, Gordon about Shadow Copy.

-LC

[Rick Houle]

Well, to round this out to the full nickel...

I have actually SOLVED a problem in the past by deleting the backup folder.

End user finds corruption, end user reverts to previous archive and end user rolls back to previous save... HOWEVER, end user fails to remove the old backup folder that is still associating itself with, da-da da, the original corruption.

We routinely remove all OLD backup folders either local or central once their time has past. I personally consider them static and bunk. A month-old roll back is not an option here. If i cannot restore a more recent save, I'm submitting the issue to Autodesk.

Central file corruption at my office is pretty rare.
IF for any reason you are uncomfortable with my method, by all means, DONT follow me. Keep to the safe side. I'm just typing my mind.
But, as the I.T. guy responsible for data restoration as well as all things Revit, I must say, my 80+ users have never lost a central file or more than 2-days work inside Revit. Good communication i guess... or just good luck.