Introduction – Why you should encrypt and secure media on‑premise
If customer data, agency assets or confidential media files pass through third‑party clouds, you lose control, traceability and often legal clarity. For freelancers, agencies and SMBs that regularly produce sensitive images, videos or documents, the combination of on‑premise hosting, encryption and thoughtful backup/retention rules is a central building block for data sovereignty and auditability.
This article shows how to secure your media storage on‑premise: which encryption options make sense, how to set up automated, encrypted backups with retention rules, and how Marqentra as a self‑hosted platform fits into these processes.
Why on‑premise media encryption makes sense
On‑premise means: the files are stored on your own server or in your own infrastructure. Advantage: you decide where keys are managed, how backups are distributed and which deletion processes apply. Encryption reduces the risk that readable files leak in the event of physical theft or unauthorized access. In combination with automatic backups and clear retention policies, you ensure that data is not kept longer than necessary and that proof of deletion exists.
Encrypting media storage – practical approaches
There are several proven layers for encrypting media on your server. It's best to combine a robust base (disk or object storage encryption) with an application layer when particularly sensitive files should be protected from tampering.
1) LUKS / Full Disk Encryption (Linux)
For Linux servers, LUKS is a common solution for encrypted partitions. Advantage: entire drives or partitions are unreadable when the system is powered off. Typical procedure:
- Format the partition with cryptsetup and create keys.
- Mount the encrypted partition at boot (e.g. via /etc/crypttab), or provide it manually for media mounts.
Note: LUKS protects files in case of physical theft. For additional security you should manage keys offline or in a KMS/HSM.
2) S3‑compatible object storage (e.g. MinIO) with server‑side encryption
If you operate an object storage instead of local file systems, MinIO or an S3‑compatible solution offers server‑side encryption (SSE). You can manage keys locally (SSE‑C or KMS integration). Advantages: granular access control, versioning and lifecycle rules at the bucket level.
3) Application layer: envelope or file encryption
On the application layer you can implement envelope encryption or per‑file encryption so that files are encrypted before they reach storage. This provides end‑to‑end protection even if the storage layer is compromised. Typical patterns include encrypting files with a data encryption key (DEK) and protecting that DEK with a master key managed in a KMS or HSM. Application‑level encryption also allows metadata to remain separate from file contents and enables selective sharing of decrypted assets.
For particularly sensitive files, additional encryption in the app is advisable. Examples: encrypt files with an asymmetric key before saving or commit them with GPG. The application stores metadata unencrypted; the asset file itself is only usable after decryption. This is more complex but provides additional protection if the filesystem is compromised.
Automated backups: encrypted, reliable, testable
Backups are useless if they are not automated, encrypted and regularly tested. Tools like restic or duplicity are common because they include encryption and support various targets (local, S3, FTP).
Concrete, practical steps
- Choose a backup tool with built‑in encryption (e.g. restic). Initialize a repository with a key that you store securely.
- Back up the media folder of your Marqentra installation specifically, not the whole system blindly. Example path in a typical web installation: /var/www/marqentra/media (paths vary).
- Automate backups via systemd timer or cronjob and log runtimes and exit codes.
- Store backups preferably in a second location (offsite or a separate data center). Ensure transport and target encryption are enabled.
- Plan and document restore tests ("perform test restores") so you know how quickly media can be made available in an emergency.
Example: basic restic commands
These commands are illustrative and show the workflow. Use your own paths and repository settings:
- restic init -r /path/to/repo
- restic backup /var/www/marqentra/media -r /path/to/repo
- restic forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 -r /path/to/repo
With the --keep options you define a simple retention policy. Adjust the intervals to your legal and operational requirements.
Retention policies and GDPR‑compliant deletion
Retention policies govern how long data is kept and when it is deleted. For GDPR compliance, proof obligations are relevant: you should be able to demonstrate that data was deleted according to internal rules or retained for legal reasons (e.g. contracts, tax law).
Concrete recommendations
- Define categories: active assets, archive, legal retention, delete hold.
- Automate moving to archive or delete buckets (e.g., object storage lifecycle rules) instead of manual deletion.
- Implement a “Legal Hold” for cases where media must be retained despite expiration. Document reasons and responsible parties.
- Document deletions with logs (audit logs), ideally generated by the application and stored immutably.
Marqentra in practice: How the platform fits into your protection
Marqentra runs on your own webspace or server. That means: you can point the storage location for media files to an encrypted partition or an encrypted object storage. Some proven integration recommendations:
- Store Marqentra media on an encrypted mount (LUKS) or an S3‑compatible MinIO bucket with server‑side encryption.
- Schedule regular, encrypted backups of the media directory and the associated metadata database. Backup tools run outside the app and secure consistent data sets.
- Use retention rules at the object storage level or in the backup tool to implement automatic deletion and archiving processes.
- If you use WordPress: Marqentra for WordPress synchronizes content; ensure that the target media storage is also encrypted and integrated into the backup strategy.
Important: Marqentra's self‑hosted architecture gives you decision authority. You choose the encryption and backup mechanisms, not an external cloud provider.
Immediately actionable steps (quick overview)
- Create a mount: set up an encrypted partition (LUKS) for /pfad/zu/marqentra/media.
- Set up backups: run restic init for an encrypted repo and schedule a daily backup job via a systemd timer.
- Define retention: configure backup retention in the tool (e.g., keep‑daily/weekly/monthly) and set lifecycle rules for object buckets.
- Test: perform regular restore tests and collect audit logs centrally.
- Document: record responsibilities, key policy and deletion processes in writing.
Conclusion
Storing media on‑premise gives you control — but also responsibility. With a combination of encrypted storage, automated encrypted backups and clear retention policies, you ensure that sensitive assets are protected, traceable and deleted on schedule. Marqentra as a self‑hosted platform integrates into this architecture: the application uses your infrastructure, you retain key authority and decide on backup and deletion cycles.
Discover Marqentra and test the demo: https://marqentra.com
Next step
Try Marqentra itself
Marqentra combines topic discovery, AI-supported content creation, media management, editorial planning, automatic publishing and analytics in a single central system. The standalone Marqentra software runs on your own webspace or server. Marqentra for WordPress is also available for WordPress.