Cách sao lưu app làm bằng AI của bạn — và tại sao bạn thực sự cần làm vậy

Một nhà sáng lập mà tôi hay nói chuyện vận hành toàn bộ doanh nghiệp đặt lịch của anh — ba địa điểm, khoảng 200 khách mỗi tuần — trên một app anh tự xây bằng một công cụ tạo app bằng AI. Anh cho tôi xem nó vào một ngày thứ Ba và rất tự hào. Đến thứ Tư, anh hỏi tôi, hơi lo lắng: “Nếu cái này hỏng, tôi có… mất sạch không?”

Câu trả lời thẳng thắn là: có thể. Tùy bạn hiểu “hỏng” nghĩa là gì. Tùy anh có kiểu sao lưu nào (anh chẳng có). Tùy anh có dựng lại nó kịp không.

Cuộc trò chuyện đó là cuộc trò chuyện phổ biến nhất mà tôi có với những người đã xây app bằng AI. Bản thân việc xây thì cảm giác như một phép màu nhỏ. Câu hỏi “chuyện gì xảy ra nếu nó biến mất” gần như không bao giờ được nhắc đến cho tới khi app đã đang làm việc thật — và đến lúc đó, hậu quả của việc mất nó đã trở nên nghiêm trọng.

Bài viết này dành cho bất kỳ ai đã tự xây một app thật, chạy được mà không phải tự viết code, và giờ phụ thuộc vào nó cho một việc gì đó quan trọng. Chúng ta sẽ bàn về cái gì thực sự đang gặp rủi ro, cần sao lưu gì, bao lâu một lần, và phải làm gì khi có việc trục trặc. Nó không mang tính kỹ thuật. Không có script nào để chạy. Mục tiêu là đảm bảo rằng dù bạn đã xây gì đi nữa, bạn cũng không mất nó chỉ vì không ai nói cho bạn biết sao lưu là một việc cần làm.

Bên trong app làm bằng AI của bạn thực sự có gì (và cái gì có thể biến mất)

Một app làm bằng AI được tạo nên từ hai thứ rất khác nhau, và bạn cần sao lưu mỗi thứ một kiểu khác nhau.

Thứ nhất là bản thân app — các màn hình, phần logic, thiết kế, các tích hợp. Đây là thứ mà công cụ AI đã tạo ra cho bạn. Nó nằm trong tài khoản công cụ AI của bạn, thường là bên trong một dự án. Nếu bạn mất quyền truy cập tài khoản đó, hoặc công cụ gặp sự cố ngừng hoạt động, hoặc dự án bị hỏng, bạn mất thứ này.

Thứ hai là dữ liệu của bạn — người dùng, đơn hàng, tin nhắn, các lượt đặt lịch, file mà người ta tải lên. Cái này thường nằm trong một cơ sở dữ liệu ở đâu đó. Đôi khi nó nằm bên trong công cụ AI. Đôi khi nó nằm trong một dịch vụ như Supabase, Firebase, hay Airtable. Đôi khi nó nằm rải rác ở nhiều nơi.

Hai thứ này có hồ sơ rủi ro hoàn toàn khác nhau. Cấu trúc app thay đổi khi bạn nhờ AI thay đổi nó. Dữ liệu của bạn thay đổi mỗi khi một người dùng làm một việc gì đó. Vì vậy chúng cần những chiến lược sao lưu khác nhau.

Một cách hữu ích để hình dung: nếu một tòa nhà cháy rụi, thì app là bản thiết kế, còn dữ liệu là những gì ở bên trong tòa nhà khi nó cháy. Bạn có thể xây lại từ bản thiết kế. Bạn không thể lấy lại những gì đã ở bên trong.

Cái gì đang gặp rủi ro: bốn kịch bản thực sự xảy ra

Tôi đã chứng kiến mỗi kịch bản này xảy ra với những người xây bằng công cụ tạo app bằng AI. Không cái nào trong số đó là lý thuyết suông.

1. Bạn vô tình bảo AI làm hỏng app. Bạn mệt, bạn làm việc lúc nửa đêm, và bạn nói “xóa trang đăng ký người dùng” vì bạn muốn thiết kế lại nó. AI làm theo. Nó cũng xóa luôn phần app cho phép người dùng hiện có đăng nhập. Giờ chẳng ai dùng được app, và phiên bản chạy được gần nhất của AI đã biến mất, trừ khi bạn đã bật lịch sử phiên bản (rất nhiều công cụ mặc định không bật).

2. Công cụ AI gặp sự cố ngừng hoạt động hoặc lỗi dữ liệu. Hiếm, nhưng có thật. Năm 2024, một nền tảng no-code phổ biến gặp sự cố ngừng hoạt động 6 giờ khi dữ liệu khách hàng không truy cập được. Không ai mất dữ liệu vĩnh viễn, nhưng rất nhiều doanh nghiệp mất một ngày. Nếu app đặt lịch của bạn sập vào sáng thứ Bảy khi khách đang cố đặt chỗ cho chiều thứ Bảy, thì đó không phải “không mất dữ liệu” — đó là doanh thu đã mất mà bạn không lấy lại được.

3. Tài khoản của bạn bị khóa. Có thể là một vấn đề thanh toán, có thể là một lượt đăng nhập bị gắn cờ từ một vị trí mới, có thể là một lần đổi email chưa được cập nhật. App vẫn ổn, dữ liệu vẫn ổn, nhưng bạn không vào được. Nếu bạn không có một bản sao đã xuất ra, bạn phải trông chờ vào thời gian phản hồi của bộ phận hỗ trợ.

4. Bạn rời khỏi nền tảng. Đây là cái mà người ta không lường trước. Một năm nữa bạn có thể muốn chuyển sang một công cụ khác, hoặc thuê một lập trình viên tiếp quản thứ bạn đã xây. Nếu bản sao duy nhất của app và dữ liệu của bạn nằm bên trong một công cụ, thì các lựa chọn của bạn sẽ hạn hẹp và tốn kém.

Trong mỗi kịch bản đó, khác biệt giữa “phiền phức” và “thảm họa” là việc bạn có một bản sao lưu hay không.

Sao lưu gì, và bao lâu một lần

Bạn không cần một hệ thống cầu kỳ. Bạn cần một thói quen. Đây là mức tối thiểu tôi khuyên cho người xây bằng AI mà không viết code.

Dữ liệu của bạn — mỗi ngày, tự động nếu được.

Nếu dữ liệu của bạn nằm trong một thứ như Supabase hay Airtable, cả hai đều có xuất hoặc sao lưu theo lịch. Hãy bật nó lên. Phần lớn người ta bỏ qua vì nó là ba cú bấm và họ nghĩ để sau làm. Hãy làm nó ngay trong ngày bạn ra mắt.

Nếu dữ liệu của bạn nằm bên trong chính công cụ AI và không có xuất tự động, hãy đặt một lời nhắc lịch mỗi Chủ nhật để xuất nó thủ công. Xuất nó dưới dạng một file CSV cho mỗi bảng. Lưu nó ở một nơi bên ngoài công cụ — Google Drive, Dropbox, một ổ cứng ngoài. Bất cứ nơi nào không phải là cùng dịch vụ đó.

Hãy giữ ít nhất bốn tuần các bản xuất này. Đừng ghi đè lên cùng một file mỗi lần. Nếu dữ liệu của bạn bị hỏng vào thứ Ba mà bạn không nhận ra cho đến thứ Sáu, bạn sẽ không muốn bản sao lưu duy nhất của mình là dữ liệu đã hỏng sẵn của thứ Sáu.

Cấu trúc app của bạn — mỗi lần bạn thực hiện một thay đổi đáng kể.

Phần lớn công cụ tạo app bằng AI đều có một dạng lịch sử phiên bản hay ảnh chụp nào đó. Hãy tìm tính năng này. Hãy dùng nó. Trước khi bạn thực hiện một thay đổi lớn cho app — và “lớn” nghĩa là “một thứ mà bạn không thể làm lại từ trí nhớ trong một giờ” — hãy chụp một bản ảnh có đặt tên. Đặt nó một cái tên hữu ích như “trước khi thêm màn hình thanh toán” hay “trước khi đổi vai trò người dùng.”

Nếu công cụ của bạn không có ảnh chụp, hãy nhờ AI tóm tắt những gì app làm trong một tài liệu dài. Lưu tài liệu đó lại. Nó không phải một bản sao lưu thật của app, nhưng nó là một công thức — nếu điều tồi tệ nhất xảy ra, bạn có thể dùng tài liệu đó như một câu lệnh để xây lại.

Tài khoản và thông tin đăng nhập của bạn — một lần, vào ngày bạn ra mắt.

Hãy ghi lại, ở một nơi, mọi thứ nằm ở đâu. Tài khoản công cụ nào chứa app. Dịch vụ cơ sở dữ liệu nào chứa dữ liệu. Email nào là tài khoản quản trị. Cổng thanh toán nào được kết nối. Những tích hợp nào được kết nối.

Hãy lưu cái này trong một trình quản lý mật khẩu, không phải một Google Doc. Nếu mai bạn bị xe đụng, người cộng sự của bạn cần tìm được tất cả những thứ này. Nếu bạn là nhà sáng lập đơn độc, thì chính bạn của tương lai (sáu tháng sau, kiệt sức, đang cố nhớ mình đã làm gì lúc ra mắt) cũng cần tìm được những thứ này.

File của bạn — bất cứ nơi nào người dùng tải lên.

Nếu app của bạn nhận file tải lên — hình ảnh, PDF, bất cứ thứ gì — những file đó nằm ở đâu đó. Hãy tìm xem ở đâu. Phần lớn công cụ dùng một dạng kho lưu trữ (storage bucket) nào đó. Kiểm tra xem nó có được sao lưu không. Nếu không, hãy thiết lập một bản sao định kỳ về kho lưu trữ của riêng bạn.

Một quy trình sao lưu đơn giản chỉ tốn khoảng 20 phút mỗi tuần

Tối Chủ nhật, lúc đằng nào bạn cũng đang không làm việc:

Mở công cụ AI của bạn. Chụp một bản ảnh có đặt tên cho trạng thái app hiện tại. Ghi ngày tháng.
Xuất mỗi bảng dữ liệu dưới dạng một file CSV. Bỏ chúng vào một thư mục có ghi ngày trong kho lưu trữ đám mây của bạn. (Phần lớn dữ liệu nằm trong 3–10 bảng — không phải việc to tát gì.)
Liếc qua kho lưu trữ của bạn. Đảm bảo không có gì kỳ quặc đang diễn ra (số lượng file tăng đột biến, các lượt tải lên đáng ngờ).
Cập nhật tài liệu “mọi thứ nằm ở đâu” nếu có gì thay đổi trong tuần này.

Vậy thôi. Hai mươi phút, mỗi tuần một lần. Đó là một khoản bảo hiểm rẻ đến mức không tương xứng với những gì nó bảo vệ.

Nếu bạn không muốn làm thủ công, hãy xem dữ liệu của bạn có nằm ở nơi nào có sao lưu sẵn không. Supabase, ví dụ, có thể tự sao lưu hằng ngày cho bạn. Nếu bạn dùng gói miễn phí của họ, các bản sao lưu đó bị giới hạn; ở gói trả phí, chúng lưu lại lâu hơn. Với một doanh nghiệp phụ thuộc vào app, gói trả phí đó là khoản bảo hiểm rẻ nhất bạn từng mua.

Phải làm gì khi có việc trục trặc

Nếu app của bạn hỏng vì một lỗi của công cụ AI hoặc một thay đổi tồi:

Đừng hoảng loạn ra lệnh. Bản năng sẽ là nhờ AI sửa nó ngay lập tức. Hãy kìm lại mười phút. Một cú sửa trong cơn hoảng theo hướng sai có thể làm mọi thứ tệ hơn, và phần lớn công cụ sẽ không dễ dàng hoàn tác một chuỗi câu lệnh.
Quay về bản ảnh gần nhất của bạn. Nếu bạn có một bản. Đây chính là toàn bộ lý do bạn đã chụp nó.
Nếu bạn không có ảnh chụp, hãy nhờ công cụ AI hoàn tác đúng thay đổi cụ thể gần nhất. Hãy nói chính xác. “Hoàn tác thay đổi mà chúng ta đã xóa trang đăng ký” tốt hơn là “làm cho nó chạy lại đi.”

Nếu dữ liệu của bạn bị hỏng:

Ngừng ghi ngay lập tức. Đưa app ngoại tuyến nếu được. Mỗi hành động của người dùng mới trong lúc dữ liệu đang xấu là thêm dữ liệu mà bạn sẽ phải đối soát về sau.
Khôi phục từ bản sao lưu tốt gần nhất của bạn. Nếu bạn không biết bản nào tốt, hãy khôi phục từng bản một vào một bản sao của môi trường cho đến khi tìm ra phiên bản sạch gần nhất.
Đối soát phần bị thiếu. Nếu bạn khôi phục bản sao lưu của Chủ nhật vào thứ Sáu, bạn đã mất năm ngày hoạt động. Hãy email cho những người dùng bị ảnh hưởng, nhờ họ làm lại việc họ đã làm, và xin lỗi. Người ta dễ thông cảm đến bất ngờ khi bạn thẳng thắn và nhanh chóng về chuyện đó.

Nếu bạn mất quyền truy cập tài khoản:

Liên hệ hỗ trợ ngay lập tức. Đừng cố “chờ cho qua.” Hàng đợi hỗ trợ của các công cụ khác nhau; có nơi rất tốt, có nơi chậm.
Chuẩn bị sẵn danh tính của bạn. Email đăng ký gốc, thông tin thẻ thanh toán, ngày bạn đăng ký, bất kỳ hóa đơn cũ nào. Khôi phục tài khoản mà thiếu những thứ này thì khó.

Điều không ai nói cho nhà sáng lập kia

Nhà sáng lập đặt lịch mà tôi mở đầu câu chuyện đã mua một gói trả phí cho dịch vụ dữ liệu của anh sau khi chúng tôi nói chuyện. Anh thiết lập sao lưu tự động hằng ngày. Anh chụp một bản ảnh app của mình. Anh ghi lại tất cả các tài khoản trong một trình quản lý mật khẩu. Toàn bộ việc đó mất của anh khoảng một giờ vào một Chủ nhật.

Một tháng sau, một thay đổi AI mà anh yêu cầu đã vô tình làm hỏng phần logic đặt lịch định kỳ của anh. Khách hàng không thấy được lịch hẹn kế tiếp của họ. Anh nhận ra trong vòng hai mươi phút. Anh khôi phục bản ảnh chỉ bằng hai cú bấm. Anh giữ được dữ liệu, giữ được app, và khách hàng của anh chẳng thấy gì cả.

Anh nói với tôi sau đó rằng đó là một giờ rẻ nhất anh từng bỏ ra. Anh không sai. Sao lưu cho một app làm bằng AI tốn khoảng một giờ thiết lập và hai mươi phút thói quen mỗi tuần. Thứ mà nó phòng tránh là cái thứ mà không ai từng mất nó nghĩ rằng sẽ xảy ra với mình.

Nếu bạn đã xây được một thứ gì đó thật, hãy chụp một bản ảnh ngay hôm nay.