Keep everything: site backup and records on Google Drive
In the previous post I wrote about the rule of understanding before you approve: what the command does, why it is needed, whether it is safe. This part is different. Now the subject is what still exists if the notebook breaks, or if an agent deletes a file.
What I wanted to solve
I work during the day, and at night and on Sundays I build with AI agents. The site has a repository. A repository, in this text, is the place where the code and the pages keep a history. That does not cover everything.
Original images and videos stay outside the site repository, in a folder of their own. Heavy files mixed with the rest make the work slow and hard to find. I needed a second place, off the notebook, with a copy and with order.
If the notebook breaks, or if an agent deletes something, the work has to stay saved and organized. The place is fixed. It is not chat.
Quick summary
- Original images and videos stay outside the site repository, in a folder of their own, with a copy on Google Drive.
- The backup uses rclone, a tool that copies files to Drive.
- I did the Google login in the browser. Before the real copy, a dry-run: it simulates what would be copied without changing anything.
- The first real backup ran around 10:23.
- ADM keeps the records on Drive, in a numbered folder tree, from inbox to archive. A file deliverable goes to Drive. Chat only says where it is.
First: what a backup is
A backup is a copy in another place. If the original goes away, the copy remains.
It is the spare house key at a relative’s place. Keeping the second key on the same keyring does not help. If the keyring goes down the drain, both keys go with it.
In practice, a program reads the source folder and writes the same files to the destination. The key comparison stops here: the spare key does not update itself when you change the lock. The backup has to run again when the files change. Yesterday’s copy does not cover today’s file.
A backup is also not “I sent it in chat.” Messages vanish, they duplicate, and a week later nobody knows which file counts. A real copy has a destination and a time.
Google Drive
Google Drive is a folder on the internet tied to your Google account. You open it in the browser, upload a file, and it stays there, off your notebook.
It is not a cupboard you can see in the room. The files go to Google’s servers. You reach them with your login, and with internet. That is why I do the login myself. An agent does not enter that account.
I use Drive. I am not selling it. It is the destination I chose for this copy.
rclone and the dry-run
Rclone is the tool that, in my case, reads the folder of originals and sends the copy to Drive.
It does not invent what to take. It copies what is in the folder you pointed at, from point A to point B. If the folder is wrong, it copies the mistake too. A human mover would see a cracked vase and ask. The program does not ask.
That is why there is a dry-run. A dry-run is a rehearsal: the program lists what it would copy and does not copy it. You look at the list. If it is wrong, you stop. Nothing was written to the destination.
I did the Google login in the browser. I operate it.
The folder tree and ADM
A folder tree is a fixed order. Names that do not change with the mood of the day. Ours is numbered. It runs from inbox to archive.
Inbox is where the file arrives. Archive, here, is the shelf for what has already been handled and still needs to stay. Between the two, work in progress.
Paper on a desk tray disappears with the desk. On Drive, the file is off the notebook.
I will not write folder identifiers or email addresses. What matters is that each kind of file has a right place.
On the team, ADM is the agent that handles personal administration. Here the job is to keep records on Drive. A file deliverable goes to Drive. The agent only says where it is, with no attachment in chat.
An attachment in chat vanishes in the thread, duplicates, and becomes “which version?”. Drive has a place. The short note points to the place.
On 3 October, ADM received the day’s record to file. “Day’s record,” in this text, means the write-up of what happened that day. I will not name the file.
What I used
I used rclone for the copy. I used Google Drive as the destination. I used the browser for the login, done by me. I used a dry-run before the real copy. I used ADM to keep records. I used this rule: the file goes to Drive, a short note goes to chat.
Account, email, and folder codes stay out of this text.
How it went
If you want to copy the logic, this is the path:
- Separate what should not go into the site repository. In my case, original images and videos, in a folder of their own.
- Choose a destination off the notebook. Mine was Google Drive.
- Do the login yourself, in the browser. An agent does not enter your account.
- Run a dry-run. When it works, you see the list of what would be copied. No new file at the destination.
- If the list is right, run the real copy. The first real backup, in my case, ran around 10:23.
- Agree with the team on the place for each kind of file. A deliverable goes to Drive. Chat only says where it is.
- When something needs filing, send it to ADM. On 3 October, the day’s record went there.
When the dry-run is right, the screen shows names and folders, without creating a file at the destination. When the real copy is right, the same names exist on Drive.
What went wrong and what I would do differently
I do not have, in this slice, a story of a broken notebook. I have the rehearsal before the copy. That is how you avoid finding the mistake after you have already written over something.
I refused to send attachments in chat. I also refused to mix heavy originals with the site repository.
The lesson for beginners: simulate before you do it, and have a fixed place for each kind of file.
If I did it again, I would write the folder tree before the first file lands in it. A folder made in a hurry, outside the order, turns into weeds. And I would read two names from the dry-run list out loud. A long list tires the eye. Two checked names already show whether the source folder is the right one.
A clean dry-run can still list the wrong folder, if I pointed at the wrong folder. The list gives me material. The decision stays mine.
Costs and limits
There is no money figure to report in this part.
What this setup does well: heavy originals outside the repository. The day’s record in one place. A deliverable that has to outlive chat.
What it does not do: replace the site repository. Code history is a different job. Media backup is this one. It also does not make the agent deserve the Google login. In this way of working, I do that login in the browser.
This is what I did, not a study. The line “if the notebook breaks, the work remains” is the reason for the choice. It is not published research.
Who it is for and who it is not for
It is for you if you already produce images or video that should not go into the site repository. It is for you if the team passes deliverables around all day and later needs to find the version that counts.
It is not for you if you only have a note in a text file and still have nothing to store. A numbered tree for a single file is theater. It is also not for you if you want the agent to do the login for you. I refuse that.
Closing
I wanted a second place for what the site repository should not carry. The originals stay outside the repository. Rclone runs with a dry-run, and the first real backup ran around 10:23. ADM files the records. Chat does not get the attachment.
The rule to copy: simulate before you do it, and have a fixed place for each kind of file.
In the next post I tell how the site went live: Cloudflare Pages and the custom domain.
If you want to follow the journey, I am on X: @RodrigoesPorto.
Sources and links
- rclone: https://rclone.org/
- Google Drive: https://www.google.com/drive/
- This site: https://rodrigoesporto.com/