Google laat gebruikers usb-sticks en hdd's opsturen voor Cloud Storage-dienst

Gebruikers kunnen hun harde schijven en usb-sticks in de toekomst opsturen naar Google om te laten opslaan bij de online-dienst. Google biedt de opvallende service aan omdat het sneller is dan grote ladingen data via bijvoorbeeld een dsl-lijn te uploaden.

De dienst wordt sinds 2013 aangeboden door Google, maar tot nu toe was het alleen mogelijk om harde schijven naar het bedrijf te sturen. Daar zijn nu meer soorten fysieke media bijgekomen. Naast harde schijven kunnen nu ook usb-sticks en tape drives opgestuurd worden. Tijdens de preview rekende Google 80 dollar per schijf voor het importeren van de data. Onduidelijk is wat Google nu voor de dienst gaat rekenen.

Op de pagina van Google Offline Media Import/Export valt te lezen dat Google het uitvoeren van de dienst overlaat aan het bedrijf Iron Mountain. Google zou binnenkort een bedrijf aanwijzen om dezelfde dienst in Europa te verlenen. Waar echter het 'export'-gedeelte van de naam van de dienst op doelt, is niet duidelijk. De concurrerende cloudplatformen van Amazon en Microsoft bieden ook zulke diensten aan.

Reacties (90)

[WokeBroke]

Hoe zit het dan als een hardeschijf of usb stick kapot aan komt. En hoe zit het met uitzonderlijke bestandsystemen?

[Kalief]

Je hebt hopelijk wel een backup van de data die je verstuurt. En voor rare bestandssystemen zul je meer moeten gaan betalen omdat dataimportbedrijf Iron Mountain er extra service voor moet gaan verlenen.

[MrFax]

Dus je stuurt een back-up naar Google, en betaald ervoor, om hem te laten back-uppen

[GoT]

Nee, je verstuurt een full load aan bestanden, zodat gebruikers ermee in the cloud kunnen werken.
Een toepassing is bijvoorbeeld dat een bedrijf wilt migreren naar de cloud en veel historische bestanden heeft die ook mee moeten.

Cloud toepassing is geen back-up.

[pe1dnn]

Cloud toepassing is geen back-up.

Het is maar wat je onder back-up verstaat

De Azure cloud dienst van Microsoft heeft bijvoorbeeld standaard 2 live kopieën die elkaar mirrorren (desgewenst op 2 fysiek verschillende locaties) en 2 schaduw kopieën. Wat je daarmee hebt is een backup tegen hardware failures en afbranden van het datacenter. Dus in de zin van beveiliging tegen kappotte schijven en systemen of ramp is het een goede vervanging voor een backup.

Waar het niet tegen beschermd zijn fouten en vergissingen. Als je je database per ongeluk weg gooit dan in hij weg op de live kopieeen en even later ook op de schaduwkopie. Bovendien kun je er niet bij de schaduwkopie want die is alleen voor het geval overhoopt toch beide live kopieeen er mee ophouden.

Kortom, je kan niet terug in de tijd en herstellen naar een eerder moment of een bestand van gisteren terughalen.

Bij transactiesystemen is herstellen naar een eerder moment al vaak een groot probleem omdat je gewoon geen transacties kwijt te raken.

Wil je bij een cloud dienst dus kunnen herstellen naar een eerder moment dan zul je zelf je backups moeten maken. Wil je je data voor de veiligheid bij een 3e neerleggen (om problemen zoals toen Megaupload werd gestopt te voorkomen) dan moet je het ook zelf doen. Maar als je gewoon 24/7 in de lucht wil blijven dan is een Cloud dienst prima en halen een hogere uptime en reduncatie dan dat je dat zelf zou kunnen.

De backups om te herstellen naar een eerder moment kun je ook zelf weer in de cloud opslaan.

Het is dus maar net wat je van een back up verwacht.

[Bastiaan V]

De letterlijke definitie van backup is "To undo one's actions".
"Cloud toepassing is geen back-up." is dus een prima statement.

[Caelestis]

Als je zou vast hangen aan dat definitie van het woord back-up dan hebben de meeste bedrijven en consumenten geen back-up.
Back-ups worden gemaakt tegen verlies van data door onvoorziene omstandigheden.
Ze worden niet gemaakt zodat je ctrl-z kan gebruiken op server niveau.

Het is een toevallige mogelijkheid wat beschikbaar is met het oude systeem en wordt alsnog vaak niet toegelaten omdat het gruwelijk veel geld kost om uit te voeren.
Een Cloud is ontwikkeld om veel problemen met oude "back-up" systemen de nek om te draaien en door het constructie is dat ene functie niet meer mogelijk wat nooit een doel is geweest van een echte IT back-up.

Dus ja dan kan je een Cloud geen back-up noemen maar wel "beveiligd opslag" en moet je ook het toevoeging maken dat een back-up volledig overbodig is geworden.

[analog_]

Net zo overbodig als backups op RAID arrays. Dat is immers ook 'beveiligd opslag'.

[Caelestis]

Het gaat om het beveiliging concept van data op software niveau.
Je begrijpt toch wel dat een Cloud ook gewoon draait op raid arrays.

Een echte Cloud (zoals MS Azure) moet je zien als een data mirror op software niveau (niet software raid mirror) waarbij er meerdere VM's tegelijkertijd draaien en als de een uitvalt blijft de ander door draaien zonder dat de Cloud opslag stopt met werken.
Zo kan je dus onderhoud, reparaties en server scaling uitvoeren zonder dat het eind gebruiker van het dienst er wat van merkt.
Tevens wordt het systeem ook gebruikt om connectie load balancing uit te voeren zodat je veel minder last heb van overbelasting of zelfs dDos aanvallen.

[riesm]

Dat CTRL-Z op serverniveau is vaker nodig dan wordt gedacht. Stel dat er een "rogue" proces op de server (of een client die connect naar de server) draait en bestanden corrumpeert. En stel dat dit pas wordt opgemerkt na een aantal dagen. Op dat moment ben je dus data kwijt, want de "backup" bevat dan alleen de gegevens van bijvoorbeeld gisteren en niet van voor het moment dat de datacorruptie plaats vond.

Er is dus een goede reden om een backupsysteem in te richten om dataverlies tegen te gaan.

Waar de cloud gemiddeld genomen in voorziet, zoals pe1dnn zo juist omschrijft, is een disaster recovery. Waar de cloud niet standaard in voorziet is een backup in de ouderwetse zin van het woord.

Het is belangrijk om te realiseren dat je dus bij clouddiensten je eigen backup moet regelen.

[Caelestis]

Het CTRL-Z opmerking is gericht op menselijke fouten dus iemand die perongeluk een bestand zelf verwijdert of een origineel document heeft herschreven zonder een revisie setup in office.

Revisie backup moet je zelf regelen met je software en je werknemers correct opleiden in plaats van af schuiven aan duur betaalde systeem beheerders.

Het probleem die je beschrijft is juist waar die Shadow Copys voor zijn die pe1dnn al aan gaf. Het systeem is de VSS "Volume Shadow Copy Service" dat steeds snap shots maakt wanneer je wilt.
Hier komt nog wel een probleem bij dat je geen snapshot kan maken van onderdelen die het VSS zelf gebruiken. Om het kort uit te leggen het kan geen snapshot maken van zichzelf.

Maar om dit te ondervangen kan je als extra optie een DPM server koppelen die het hele configuratie voor een korte tijd kan bewaren. Afhankelijk wat je wil kan dat 30 tot 120 dagen retentie bevatten.

Het gaat erom dat een Cloud juist het evolutie is van beveiligd opslag en dat het concept van een standaard back-up systeem terug te vinden is in het constructie en maar een klein onderdeel is geworden van wat er nu als beveiligd opslag gezien wordt.

[bassieboy1990]

Nee, je stuurt je data op naar Google om deze secuur te laten opslaan in een cloud dienst.

Waarbij je hopelijk OOK een harde schijf thuis heb met de data.

[m8ZBm1Si]

Uitzonderlijke bestandssystemen zullen niet supported zijn. Dus zul je je data op een harde schijf met een wat bekender bestandssysteem moeten zetten.

[pe1dnn]

Die kun je dan altijd nog als dump van de hele disk opslaan...

dd if=/dev/hda of=customerdisk.img

[BlueLed]

Bestand extensies bedoel je?

[gjmi]

Bestandextensies maken niets uit. Bestanden word alleen gekopieerd, niet ingekeken. Het maakt niet uit of het appels of peren zijn.
Het bestandssysteem echter maakt wel uit. Windows gebruikt een ander bestandssysteem dan Linux en dat is weer anders bij MacOS. En dan hebben we bet nog niet over tientallen andere exoten. Niet elk bestandssysteem kan zomaar door bijvoorbeeld Windows gelezen worden. Windows weet niet hoe de bestanden geschreven zijn op een EXT4 systeem. Blokgrootte, directory structuur, indexen enzo zijn allemaal anders. Met een speciale driver kan dat dan weer wel.

[Reactie gewijzigd door gjmi op 25 juli 2024 02:33]

[Caelestis]

Google gebruikt geen windows servers maar juist linux. Bestandssysteem is daarom nagenoeg onbelangrijk omdat linux vrijwel elke systeem aan kan. En dan als extra gebruiken ze een zelf ontwikkeld bestandssysteem dat GFS heet.
Dus ongeacht wat je als consument of bedrijf zou kunnen opsturen komt het niet overeen met de Google servers.

[gjmi]

dat snap ik wel, ik probeerde alleen uit te leggen aan BlueLed waarom extensie niet uitmaakte maar systeem wel.

En Linux leest ook niet standaard zomaar alle bestandssystemen.

[Caelestis]

Standaard niet nee met bepaalde distro's maar ondersteuning toevoegen is super makkelijk en veel betrouwbaarder dan met windows of macOS.

[gjmi]

Ja, dat snap ik allemaal wel!?
Ik begrijp niet zo goed waarom je doorgaat over Linux?? Ik gaf maar een voorbeeld!

Ik zou trouwens niet durven zeggen dat het betrouwbaarder is. Ik heb goede ervaringen met drivers voor andere bestandssystemen op MacOS en Windows. Maar het werkt altijd nog het betrouwbaarst op het systeem waarvoor het ontworpen is

[i-chat]

Ja, dat snap ik allemaal wel!?
Ik begrijp niet zo goed waarom je doorgaat over Linux?? Ik gaf maar een voorbeeld!

Ik zou trouwens niet durven zeggen dat het betrouwbaarder is. Ik heb goede ervaringen met drivers voor andere bestandssystemen op MacOS en Windows. Maar het werkt altijd nog het betrouwbaarst op het systeem waarvoor het ontworpen is

alleen als je zfs op solaris of bsd bedoeld want anders wil ik je toch weizen op het feit dat er heel wat filesystems zijn die niet al te stabiel zijn zoals fat32 onder windows,

[gjmi]

???? Wederom: dat snap ik wel!
Maar het gaat er hier niet over welk bestandssysteem het stabiel zijn en welke niet. Dus ik snap niet waarom je deze opmerking plaatst.

[RGAT]

Het smaakje wat de Google servers draait maakt verder niets uit voor deze dienst tenzij elke hdd direct in het Google datacenter met een usb kabeltje oid aan een fysieke server wordt gehangen (virus anyone?)
Zal gewoon op een kantoor komen met Windows/Linux computers en van daaruit naar de cloud gestuurd worden over een dikke verbinding.
De ondersteuning van bestandssystemen zal dus vrij ruim zijn

[DeEchteKwartel]

Nee, bestandsystemen. Extensies zijn niets anders dan onderdeel van de bestandsnaam.
Bestandsystemen zijn dingen als FAT32, NTFS, EXT2/3/4, etc

[Kafka]

En hoe zit het als er een aardbeving komt? Dan is m'n harde schijf kapot!

[Verwijderd]

En wanneer je vraagt om een restore, sturen ze dan ook een HD of USB stick terug ?? Of moet ik dan gewoon een week geduld hebben ....

[svennd]

Dan download je uit de cloud

[Verwijderd]

En dát duurt dus gewoon een week als het een beetje een hoeveelheid data is...

[SunnieNL]

Upload is meestal trager dan download. Scheelt bij mij een factor 10

[BlakHawk]

Als je kabel of DSL hebt wel ja, maar lang leve glasvezel!

[Verwijderd]

Deze diensten worden vooral aangeboden zodat je de overstap naar een (managed) cloudomgeving kunt maken.

Lokaal heb je die data dan vaak niet eens meer nodig. Een restore kun je gewoon in bijv. een datacenter laten uitvoeren met de door jou gekozen backupoplossing.

Daar ben je dus helemaal niet lang mee bezig.

[RGAT]

Denk dat dat het 'export' deel van deze dienst is.
Backblaze biedt iig aan een 3-4TB disk (of meerdere) voor je te kopen en te vullen met je online data en die op te sturen, neem aan dat Google hier ook in mee zal gaan.
Of je dan bij Google je eigen disks/sticks/tapes moet opsturen voordat ze gevuld worden of Google nieuwe voor je koopt en opstuurt wat een stuk sneller maar ook duurder zal zijn.
Denk dat het voor Google ook administratief een heel gedoe wordt om bij te houden welke data op welke hardeschrijf, usb stick en tape moet en ze dan gewoon hun eigen hardeschrijven ervoor gebruiken en die opsturen.

[PegOpDeWeg]

Snap het probleem niet zo. Zet je upload/sync aan. Je gaat naat bed en de volgende ochtend staat alles erop. Of is dit voor mensen die nog met een modem uploaden?

[Coach4All]

Er zijn mensen (cq providers) die nog een limiet hebben qua dataverkeer....

[ShellGhost]

Dat niet alleen, in eens even een tera aan data overpompen kan even gaan duren. Niet iedereen heeft een fiberverbinding.

[Ursamajor]

ik weet niet wat voor een uploadsnelheid jij hebt, maar een paar terabyte uploaden die ik niet in een nachtje. Bedrijven al helemaal niet.

[Argonar]

Dat kan, maar de statement bedrijven al helemaal niet? zakelijk internet is meer gericht op upload dan download... (onder andere door voip en what not, maar ook voor cloud diensten), dat gaat dus niet helemaal op je statement.

Komt bij dat bijvoorbeeld zakelijk van ziggo tegen 40mbit ligt aan upload, wellicht kan dat hoger? Ik ben voor de rest nogal onwetend, meer omdat die informatie ook vaker alleen aan bedrijven wordt gericht.

[Reactie gewijzigd door Argonar op 25 juli 2024 02:33]

[aadje93]

niet elk bedrijf heeft "maar" 100gb wat ze de cloud in willen brengen, bedrijven kunnen soms terabytes aan data hebben die in de cloud moeten, met 100mbit upload duurt het dan wel even

Ik heb ooit wel is een video gezien waarin de vergelijking tussen een pakket HDD's met fedex express (westcoast naar east coast of andersom) gedaan werd vs internet. Fedex was sneller vanaf een paar TB's inclusief de schrijfsnelheden van de afzonderlijke hdd's bij elkaar opgeteld gezien ze parallel in de cloud gebracht kunnen worden.

[Sandwalker]

Ja nogal wides. Met een 100Mbit lijntje krijg je nooit meer dan 12.5MB per seconde (ja ik weet het, eigenlijk moet de overhead er nog af). Een TB aan data versturen kost je dan ongeveer 22 uur. Wordt het meer dan dat, en dat is echt niet gek voor een zakelijke setting dan is het vaak nog sneller om zelf even langs te rijden met de data dan om te uploaden. Opsturen vraagt wel om een goede key infrastructuur. Ik zou mijn bedrijfsdata niet graag in de post naar Google doen, tenzij ik de boel sterk kan versleutelen.

[iAR]

Juist, want je houdt een winterslaap als je 10 TB upload?

[svennd]

enkele Tb aan data ?

[i-chat]

Snap het probleem niet zo. Zet je upload/sync aan. Je gaat naat bed en de volgende ochtend staat alles erop. Of is dit voor mensen die nog met een modem uploaden?

hier in nl mag dat misschien zo zijn maar er zijn hele gebieden (zelfs binnen de eu) waar de upload niet boven de 1mbit uit komt, ik zou niet graag 2tb data wille uploaden met 1mbit/s 2tb (give or take), zou je al ruim 185dagen kosten, dat is ruim een half jaar uploaden,

maar anderzijds ik vraag me echt af of zo'n dienst wel zin heeft, ik bedoel, er zullen een hoop zolderkamerbedrijfjes zijn die met hun pappa's 500/500 ftth lijntje het zelfde kunnen doen voor 1 a 2 tientjes...

[RGAT]

Niet iedereen heeft een grote snelle verbinding of minder dan enkele GB's aan data die in 1 nachtje over kunnen.
Zeker voor 'tweakers' kan er nog wel eens een tiental TB's of meer zijn, welliswaar een flinke verbinding maar ook op 1Gb duurt 40TB uploaden een tijdje
Daarbij is vooral de upload vaak 1/10 van de download snelheid, behalve met glasvezel waar het vaak gelijk of iig meer bij elkaar ligt.
Dus met Ziggo kan het zo zijn dat je met 6Mb/s upload, als we er vanuit gaan dat je constant de volle 6Mb/s haalt zou 40TB (virtuele machines vooral maar ook e.a. aan backups en de normale data zoals foto's), als je alleen 's nachts zou uploaden van 23:00 tot 07:00 zou het ongeveer 6.34 jaar duren...
(En voor de comment die er waarschijnlijk aan komt 'maar de meesten hebben niet 40TB, die meesten gebruiken dan ook niet deze service van Google en zijn dan ook niet relevant hierin )

[Reactie gewijzigd door RGAT op 25 juli 2024 02:33]

[m8ZBm1Si]

Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.
—Tanenbaum, Andrew S. (1989)

Mooi dat ze dit ook gaan aanbieden. Voor veel clouddiensten met gigantisch veel data is het via internet versturen nog geen oplossing. De harde schijven versturen is dan vaak sneller.

[Reactie gewijzigd door m8ZBm1Si op 25 juli 2024 02:33]

[Dual Infinity]

'Never underestimate the bandwidth of a truck.'

Laten we het dan wel goed doen:
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.
—Tanenbaum, Andrew S. (1989)

[m8ZBm1Si]

Fixed! Ik had hem gehoord als truck een paar jaar terug, maar dat is duidelijk een variant op deze, dus aangepast!

[Tweaker626]

Sneakernet is back!
https://en.wikipedia.org/wiki/Sneakernet

[Verwijderd]

Da's een mooie term, die kende ik nog niet!

[mrfu]

Wat gebeurt er met die duizenden (of meer) harde schijven (en nu dus ook USB sticks) die Google ontvangt nadat de data de 'cloud' in is geknald?

[svennd]

return to sender zou ik denken.

[FreshMaker]

Wat gebeurt er met die duizenden (of meer) harde schijven (en nu dus ook USB sticks) die Google ontvangt nadat de data de 'cloud' in is geknald?

die worden voor de 'gratis' google drive ingezet

[Fiber]

LOL, Moest toch weer even denken aan die prachtige quote van Andrew S. Tanenbaum: Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway...!

[Wom]

Iron Mountain is ook actief in Europa, lijkt me de meest logische stap dat zij dan ook in Europa deze dienst zal verlenen en verzorgen voor Google?

[Joep63]

Dit geeft de beperkingen van de Cloud aan. De praktische bandbreedte en betrouwbaarheid is toch vaak beperkt doordat de toegang van vele factoren afhankelijk is: LAN/wifi verbinding, provider netwerk, cloud provider.

Ik hecht toch aan een NAS op het lokale LAN. Zelfs als ik een groot bestand op mijn laptop wil downloaden is het sneller het eerst op de NAS te downloaden en dan via wifi op de laptop daarvan af te halen als het rechtstreeks via wifi van het internet af te halen. Ook met storingen zoals laatst bij Ziggo heb je al je bestanden nog bij de hand.

Ook op mijn werk wordt alles steeds vaker op servers in andere lokaties opgeslagen en gaat de snelheid en betrouwbaarheid daardoor achteruit.

Voor mijzelf zijn dan ook de uitgangspunten:
Vast bedraad als het kan wifi als het moet.
Data zo dicht mogelijk bij opslaan en alleen verder weg als dat noodzakelijk is omdat het van meerdere plekken toegankelijk moet zijn. Wel zorgen voor goede backups liefst op een andere lokatie.

[Verwijderd]

Jouw scenario is eigenlijk ook niet ideaal.
Als jij bijvoorbeeld een RDS gebruikt, heb je in principe geen data lokaal meer nodig. AL je data en applicaties zullen op een andere locatie staan.

Het enige wat je dan nog lokaal/thuis nodig hebt is een internetverbinding. Een beetje router ondersteunt gewoon failover verbindingen. Mocht je internet er dus uit liggen, dan kun je altijd terugschakelen naar je backupverbinding.

[RGAT]

Zowel de cloud als je nas hadden nog gewoon gewerkt met de 'storing' van Ziggo aangezien iedere tweaker wel een andere DNS server kan instellen toch?
Het hangt er volledig van af wat je nodig hebt, heb zelf ook de storage in huis staan, maar Backblaze (cloud) houdt een kopie van de backups bij mocht er ooit brand uit breken of dieven in breken (please not...)....
Sowieso heb ik thuis veel sneller internet dan ik meestal op visite of in de trein heb, dus cloud/nas snelheid maakt voor mij niks uit.

Overigens de eerste factoren die je noemt 'Lan/wifi' heb je natuurlijk met de NAS ook he

Ben zelf aan het verhuizen op het moment en had de meest belangrijke data ook nog even los op de cloud gezet en moet zeggen dat het heel fijn was daar gewoon bij te kunnen zonder eerst mijn storage en hele boel mee te slepen

[Yaz]

Dat ze hier geld voor vragen. Volgens mij is deze dienst bij Amazone en Microsoft gewoon gratis.

[dimitrivs]

Gelijkaardige prijzen:
https://aws.amazon.com/importexport/pricing/
http://azure.microsoft.co...ls/storage-import-export/

[MAX3400]

Niet helemaal aangezien Microsoft specifieke eisen stelt aan de storage namelijk "industry standard SATA3.0 drives up to 6TB/drive". Google lijkt ook de mogelijkheid tegen om andere media, zoals backup-tapes te laten importeren.

Het grote nadeel van Azure (nu) vind ik dat je een 6TB drive kan opsturen maar deze wordt, afhankelijk van je Storage Subscription, niet geimporteerd omdat je bijvoorbeeld maar 1TB allocaties hebt. Of alles wordt/moet gesplitst aangeleverd tegen meerprijs en per blob/account worden gekoppeld.

[steveman]

Leek me al sterk dat ze dit gratis zouden doen...

https://aws.amazon.com/importexport/pricing/

Amazon schijnt er ook $80 voor te vragen, plus de tijd die het overdragen van de data kost voor $2.49.

Nu durf ik zonder het op te zoeken wel te beweren dat Microsoft het ook niet gratis doet.

[Verwijderd]

Dergelijke features zijn er niet zozeer omdat Google er geld wil verdienen. Deze worden opgetuigd omdat er blijkbaar vraag is van bedrijven. Ik denk niet dat mensen die gebruik willen maken van dit soort functionaliteit wakker liggen van de kosten. Het zal voornamelijk om B2B gaan.

Misschien interessant voor sommige mensen om te weten. Je kunt buiten de standaard Cloud Storage ook kiezen voor Nearline, wat gemaakt is vooral voor archiveren en niet high-performance tegen wat lagere kosten:
https://cloud.google.com/storage/docs/nearline

"Google Cloud Storage Nearline is a low-cost, highly-durable storage service for data archiving, online backup, and disaster recovery. "