Se desean sugerencias para volver a trabajar la carga de archivos> almacenamiento -> flujo de copia de seguridad

Estoy trabajando en un sitio web comercial donde se cargan archivos de video, generalmente de 4 a 10 mb cada uno, y aproximadamente 200 mb por mes en total. Los videos no se hacen públicos, se suben para que sean revisados ​​por una persona específica.

En la actualidad, los visitantes cargan videos a través de un script PHP que almacena el archivo en un directorio en el servidor web y notifica al administrador con un enlace directamente al archivo donde el administrador puede ver/descargar.

Cada par de meses se toma una copia de este directorio y se entrega al administrador, luego se borra el directorio para que el sitio no ocupe demasiado espacio. Esta copia luego se agrega a una copia de seguridad en otro servidor.

¿Qué sería un mejor flujo? Estoy pensando que podríamos estar subiendo a un servicio de almacenamiento de archivos en la nube en lugar de al servidor web en sí. Eso eliminaría los primeros pasos e incluso podría reemplazar su copia de seguridad también ...

0

1 Respuestas

Amazon's S3 Storage pricing looks like it'd be quite reasonable for your application. You'd be in the lowest usage tiers on all their categories:

Storage Pricing
                     Standard Storage    Reduced Redundancy Storage
First 1 TB/month   $0.140 per GB       $0.093 per GB

Request Pricing
PUT, COPY, POST, or LIST Requests   $0.01 per  1,000 requests
GET and all other Requests          $0.01 per 10,000 requests

Data Transfer Pricing
Data Transfer OUT
First 1 GB/month     $0.000 per GB
Up to 10 TB/month     $0.120 per GB

Se sugiere "Redundancia reducida" para proporcionar cuatro nueves (99.99%) disponibilidad - lo que equivale a aproximadamente 53 minutos de tiempo de inactividad cada año. Bastante bueno. "Almacenamiento estándar" tenía suficientes nueves en su calculadora de precios herramienta que puede suponer que solo los eventos catastróficos reducirían su datos. Sería la opción que escogería si fuera a evitar copias de seguridad. por completo y confíe en Amazon para copias de seguridad.

Supongamos después de dos años de operación y un crecimiento doble anual: 1000 Megabytes de cargas por mes: 12 gigabytes de almacenamiento, eso es menos de $ 2 Al mes por almacenamiento al cabo de dos años. (Será más barato antes entonces.)

Sus solicitudes de PUT serán tan poco frecuentes (40-120 por mes) que podría así como fingir que son $ 0 por mes.

Sus solicitudes de GET serán tan poco frecuentes (80-240 por mes, asumiendo que ambas El visualizador designado del cargador y descarga el contenido una vez cada uno) que Podrías fingir que son libres para siempre. (¿Centavo por 10,000? Wow.)

Si asume dos gigabytes de datos cada mes (esto es dos años fuera Punto de vista del crecimiento de dos años: 200 megas se convierten en 400, 800 y suponen tanto el cargador de video como el visor designado descargan cada video exactamente una vez, eso es 1600 megabytes), eso será otros $ 0.24 por mes.

Asumiendo tasas de crecimiento decentes y mirando dos años en el futuro para ver cómo se ve el almacenamiento acumulado, será de aproximadamente $ 2.25 por mes para Sus costos de alojamiento de datos.

Pero el almacenamiento S3 solo tiene sentido si está preparado para modificar sus herramientas existentes para cargarlas en los depósitos de almacenamiento S3. Es posible que tenga que esforzarse más para que su espectador designado "vea" el contenido; de hecho, el método más sencillo podría descargar temporalmente el contenido del depósito de S3 a su servidor web para ofrecer la posibilidad de volver a descargarlo a sus espectadores, o Es posible que necesite escribir una herramienta que pueda hablar S3 para descargar el contenido directamente en su escritorio del espectador. (Hay bibliotecas para Python y Ruby, probablemente otras también; la herramienta s3cmd también podría Ser útil para herramientas rápidas y sucias.

0
agregado