Storage, Backup & Security
Classify materials by how critical, sensitive and difficult to replace they are
The storage strategy should reflect the project's actual risks, not only the amount of storage available.
These storage roles should be kept deliberately separate
The file currently being edited is not a backup of itself.
Deleted, damaged or encrypted files can also propagate into synchronised locations.
A backup supports recovery after loss or error; long-term preservation also requires appropriate formats, documentation and responsibility.
Being able to access a file does not automatically mean it may legally be used, shared or published.
The specific service, responsibility, access model, protection needs, export options and institutional requirements still matter.
A backup is practically useful only if it is clear how a needed file can actually be restored.
Set one authoritative working environment and clear access roles
Choose the working location
Define where the authoritative active project copy lives and which systems are intended for that purpose.
Assign responsibility
Decide who manages storage locations, permissions and technical handover.
Assign access by role
Grant only the rights required for each task and avoid unnecessarily broad permissions.
Plan external collaboration
Clarify how partners gain access, how access ends and how materials are handed over after the project.
Separate sensitive areas
Keep especially protected materials separate where different access rules are necessary.
Identify master and working copies
Make clear which version is authoritative and which local or temporary copies exist only for editing.
Review access
Check permissions when roles or partners change, at milestones and before project closure.
Plan handover
Document which storage locations, accounts and permissions will continue, transfer or close when the project ends.
Define not only that backups exist, but what is backed up, how often and how it is restored
Define backup scope
Specify which files, databases, configurations, documentation or project materials need to be backed up.
Choose frequency according to change
The more frequently irreplaceable material changes, the shorter the useful backup interval should be.
Check independence
Avoid having the working copy and the only backup depend on the same device, account or failure path.
Include versions where needed
Keep recoverable earlier states where accidental changes or deletions need to be reversible.
Know the recovery route
Document who can restore files, where backups are located and which steps are required when something goes wrong.
Test recovery
Use a harmless test file to confirm that a backup can actually be found and restored.
Update the strategy
Adjust it when data volume, tools, partners, storage locations or protection needs change.
Account for project closure
Keep active backup routines separate from the decision about what should be preserved, archived, deposited or deleted long term.
Different materials can create very different storage requirements
Large audio, video or image collections
Plan capacity, transfer times, working copies, master files and backup so that large volumes do not exist only on individual local devices.
Personal or confidential data
Restrict access, document responsibility and separate especially protected areas from generally accessible project files.
Collaborative project work
Define one shared working location, clear permissions and a handover process for partners and changing roles.
Code, software & technical environments
Where relevant, back up not only files but also configuration, dependencies and information needed to rebuild the working environment.
Ephemeral or difficult-to-reproduce work
If material cannot simply be recreated, define and review the backup strategy particularly early.
Project closure & handover
Make sure master files, documentation, storage locations and responsibilities do not remain tied to personal accounts or individual devices.
A short storage and backup plan makes responsibilities traceable
Keep the agreed standard where the project team will actually find it — for example in the project folder, DMP or a technical README.
| Element | What to record | Why it matters |
|---|---|---|
| Authoritative working location | System, folder or service containing the active project copy. | Prevents several unclear competing main copies. |
| Responsibility | Who manages storage, permissions and technical handover. | Makes responsibility clear in daily work and during incidents. |
| Access model | Which roles may read, edit or administer. | Reduces unnecessarily broad access. |
| Backup scope | Which materials and systems are backed up. | Prevents gaps between important work and actual backups. |
| Backup frequency | How often backups or recoverable versions are created. | Determines how much work could be lost in a failure. |
| Recovery | Who can restore and how the restore process works. | Turns existing backups into a usable recovery strategy. |
| Sensitive areas | Which materials need additional access or protection measures. | Connects technical storage to data protection and confidentiality. |
| Project closure | What is handed over, preserved, deposited, archived or deleted. | Separates active backup from long-term responsibility. |
Common warning signs in storage, backup and security
The specific service, responsibility, recovery process and access rules may still be undefined.
A single device remains a single point of failure.
Errors, deletions or unwanted changes can also affect synchronised copies.
It is unclear whether the backup is actually usable when needed.
Roles and protection needs have not been translated into an appropriate access model.
Access, responsibility and handover may be at risk when roles change or the project ends.
Who is responsible for storage, backup and security questions
Storage and backup are closely connected to these decisions
Training, workshops & consultation sessions
Relevant opportunities for this topic will be shown here automatically from the central calendar.
COMING SOON